Re: [PATCH] xgettext: make c-format guessing slightly more intelligent.

[Gaute B Strokkenes]

On Tue, 10 Jul 2001, address@hidden wrote:
> Gaute B Strokkenes writes:

> A workaround for this is found in the gettext documentation, section
> "Special Comments preceding Keywords". Namely, use
> xgettext:no-c-format in a comment preceding that line.

Yup, that's what we're doing.

>> After some digging, I found out that this is because a space
>> actually has a well-defined meaning in this context; but only if a
>> floating-point value is being printed
> 
> This is not true. A space is meaningful for "signed conversions",
> and %i is one of them. See ISO C 99 section 7.19.6.1.

And bing, the light goes on.  Never mind.

Anyway, I have another patch, and this one fixes a _real_ bug.

--- xgettext.c  Tue Jul 10 23:06:47 2001
+++ xgettext.c  Tue Jul 10 23:05:26 2001
@@ -1380,7 +1380,8 @@
       size_t dummy;
 
       (void) parse_one_spec (s, 0, &spec, &dummy);
-      if (strchr ("iduoxXeEfgGcspnm%", spec.info.spec) == NULL)
+      if (strchr ("iduoxXeEfgGcspnm%", spec.info.spec) == NULL
+         || !spec.info.spec)   /* "This is 50%." */
        return impossible;
     }
 
You need this because of a misfeature of strchr().  If the second
argument is 0, then it returns the address of the string's terminating
NUL.  This causes stuff like "One half is 50%." to be marked as
c-format.

>> One aber is that I'm not sure if I ought to check for PA_FLOAT as
>> well.  The glibc manual mentions it, but it's never set in
>> parse_one_spec().
> 
> It's not needed because printf being a varargs function, all 'float'
> arguments are automatically converted to 'double' before the printf
> function is called.

Precisely, but it does make you wonder why PA_FLOAT even exists.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
PARDON me, am I speaking ENGLISH?