Bug 489 - d_printf() cannot handle '\"'
Summary: d_printf() cannot handle '\"'
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: SWAT (show other bugs)
Version: 3.0.0preX
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Tim Potter
QA Contact:
Depends on:
Blocks: 413
  Show dependency treegraph
Reported: 2003-09-22 13:15 UTC by TAKAHASHI Motonobu
Modified: 2005-08-24 10:20 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description TAKAHASHI Motonobu 2003-09-22 13:15:05 UTC
d_printf() cannot handle messege strings including '\"', for example
"this is a \"test\"." or swat.c:980, 996 , ...

To fix this problem or to modify messege strings not to include '\"' is required
to support SWAT i18n function.
Comment 1 Tim Potter 2003-09-22 21:51:54 UTC
Reassigning to me.
Comment 2 Tim Potter 2003-09-23 00:23:17 UTC
This is a problem with passing the msgid as both a tdb key and as
an entry in the msg file.  The msg file retains the \" while the
C compiler eats the backslash, so a comparison between the escaped
and unescaped strings will fail.

A solution is to do a substitution of " with \" in lang_msg() but
this will increase the size of the string and possibly create
a bit of a mess.  It could be easier just to change the \" to '
Comment 3 TAKAHASHI Motonobu 2003-09-23 01:10:19 UTC
The BUG#412 is occurred by similar reason.

I think we need to decide totally 
how to do against such kind of letters.

As you said, to avoid to use such characters 
is one solution, I think. But this is not good.

I think to decide that is better maybe

1) " \ and other ASCII chars should be permitted 
  even if Samba 3.0.0 will be shipped to apply 
  your quick solution.

2) Escaped characters except 1) (i.e. \n, \t) may
   not be permitted in the string for d_printf().
Comment 4 Tim Potter 2003-09-25 18:24:10 UTC
I have a patch to allow d_printf() to handle escaped " characters, i.e I
implemented the second paragraph of comment 2 which turned out to be not so hard
after all.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-02-07 09:05:18 UTC
originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:20:47 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.