Re: Hungarian notation

[kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3606 bytes --]


In article <832631288snz@tsys.demon.co.uk> Tom Wheeley
<tomw@tsys.demon.co.uk> writes:

|> In article <KANZE.96May20192546@slsvgqt.lts.sel.alcatel.de>
|>            kanze@lts.sel.alcatel.de "James Kanze US/ESC 60/3/141 #40763" writes:

|> > 
|> > |> "cannot" is too strong. The C language clearly allows the compiler to
|> > |> know about standard library functions like printf. In fact at least
|> > |> one free compiler does check the arguments against the formatting
|> > |> directive, and more should do.
|> > 
|> > This must be an amazingly brillant compiler, since the format strings
|> > are almost always the result of a call to gettext (or its equivalent on
|> > non-Unix systems), which means that they are read from an external file
|> > which generally won't even exist on the machine which is doing the
|> > compiling.  Or does this compiler also know the semantics of gettext,

|> The check is simply based on (AFAICS) a string literal format string
|> (I cannot think of a good reason why not to use a literal format string, as
|> you have that much more control over it.)

The problem is that the the string must change according to the locale,
and of course, the locale is not known until run-time.

|> > and simply suppose that the translators won't screw it up.  (Wishful
|> > thinking, of course.  But I guess it really is too much to ask for a
|> > warning along the lines of: ``Warning: the translator who does the
|> > Estonian localization 5 years from now will accidentally change the %d
|> > into a %s.'')

|> Surely the localisation would not involve the changing of types, thus
|> language specific text can be simply included via %s.  Ok so it may be a
|> tad slower, but it is a hell of a lot safer.

The localisation *shouldn't* involve changing types.  In reality, the
person typing in the foreign language text may make a mistake.  (In my
experience, this most often happens when using the X/Open extension
with positional parameters.  The types get swapped.)

I've "solved" the problem by using C++, and designing a special
type-safe interface.  But I think you have found the correct solution
for C: do all type conversions using sprintf, and only allow "%s" in
the translatable string.  It should be simple to provide a wrapper for
gettext, which verifies this (and also that the number of %'s is
correct). 

|> At least, I *think* that that is what you are talking about.  You would
|> use printf(s); instead of printf("%s",s); ?  Especially if reading from a
|> file, I would never make code so easily breakable.

It *does* make code easily breakable (although the file is not
generally writable by the user).  I wish I'd thought of your solution,
above, when I was still using C.

More generally, since the results of gettext are so often used as a
format string for printf, wouldn't it be nice if the vendors provided a
version which validated the imported string.  (For those unfamiliar
with gettext: the function uses a string to look up a locale specific
string.  If it cannot find the locale specific string, it returns the
selector string, which normally corresponds to the text in the "C"
locale.  A checking version could thus verify that the conversion
specifiers in the locale specific string correspond exactly to those in
the selecting string.)
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, �tudes et r�alisations en logiciel orient� objet --
                -- A la recherche d'une activit� dans une region francophone