-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 2/28/2009 8:05 AM:
> Thanks. Still, I prefer to separate the two tests: It takes more time
> to understand a test if it's clobbering the input data of the previous
> test.
>
> Also, in the doc I prefer to keep a canonical
Eric Blake wrote:
> Even worse. Cygwin 1.5.x appears to do just fine on 2-character strings,
> but mishandles 1-character strings, always returning -1, and without
> setting errno!
Very weird: on OpenBSD the strings of length 1 work and the larger ones
fail, and on Cygwin 1.5 it's just the opposi
Eric Blake byu.net> writes:
> +# printf.m4 serial 32
> dnl Copyright (C) 2003, 2007-2009 Free Software Foundation, Inc.
> dnl This file is free software; the Free Software Foundation
> dnl gives unlimited permission to copy and/or distribute it,
> @@ -653,13 +653,19 @@ int main ()
> {
>ch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 2/27/2009 4:22 AM:
> Eric Blake wrote:
>>> if (sprintf (buf, "%ls", wstring) != -1)
>>> return 2;
>>> because it does not fail on any known platform.
>> Actually, it DOES fail, on cygwin 1.7.0. But that is due to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 2/26/2009 7:49 PM:
> According to Bruno Haible on 2/26/2009 6:13 PM:
>> I removed the part of the test that should normally always fail:
>> if (sprintf (buf, "%ls", wstring) != -1)
>> return 2;
>> because it does no
Eric Blake wrote:
> > if (sprintf (buf, "%ls", wstring) != -1)
> > return 2;
> > because it does not fail on any known platform.
>
> Actually, it DOES fail, on cygwin 1.7.0. But that is due to a bug in
> cygwin wctomb[1]
So, activating the *printf replacements for this bug would not he
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 2/26/2009 6:13 PM:
>
> I removed the part of the test that should normally always fail:
> if (sprintf (buf, "%ls", wstring) != -1)
> return 2;
> because it does not fail on any known platform.
Actually, it DOES
Hi Eric,
> I'm now getting failures on Solaris 10, at the same line, and traced it to a
> call to the native:
>
> /* second byte uninitialized, and happens to be invalid character */
> wchar_t str[2] = { 'a', 0x65666768 };
> snprintf(buffer, 12, "%.*ls", 1, str);
>
> with a return of returns -1
Eric Blake wrote:
> > +static wchar_t wstring[] = { 'a', 'b', 'c', 0 };
>
> Are we guaranteed that on all platforms, 'a' promotes to L'a'? Or should
> we explicitly write the latter?
It is guaranteed: ISO C 99 paragraph 7.17.(2) says:
"wchar_t
... is an integer type whose range of values ca
Bruno Haible clisp.org> writes:
>
> Thanks for these findings! It's not only "%.*ls" which has the bug, but also
> "%ls" without a precision. I'm applying this workaround:
>
>
> 2009-02-26 Bruno Haible clisp.org>
>
> Fix *printf behaviour regarding the %ls directive.
I'm now getting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 2/26/2009 4:54 AM:
>
> Thanks for these findings! It's not only "%.*ls" which has the bug, but also
> "%ls" without a precision. I'm applying this workaround:
>
> +static wchar_t wstring[] = { 'a', 'b', 'c', 0 };
Are we
Eric Blake byu.net> writes:
> git reset --hard e8e63
> ./gnulib-tool --with-tests --test vasprintf-posix
>
> fails:
>
> ../../gltests/test-vasprintf-posix.c:3624: assertion failed
> Abort trap
> FAIL: test-vasprintf-posix
>
> In the debugger, I see that vasprintf(&result,"%.*ls",2,L"ab") is s
Bruno Haible clisp.org> writes:
>
> There is also a more complicated case: when a %ls directive occurs
> in a char* format string, or a %s directive in a wchar_t* format string.
> In these two cases, the only robust fix that I see is to implement the
> entire handling of this directive ourselves
Ben Pfaff wrote:
> it only did it after I had done some manual editing of Makefiles,
> etc. produced by configure, and much source hacking.
Somhoew this must have led to a situation where HAVE_SNPRINTF = 0.
> So to make sure that it could really happen in a simple test
> case, I forced !USE_SNPRI
Bruno Haible writes:
>> The culprit is pretty clearly this code in lib/vasnprintf.c:
>>
>> case 's':
>> [...]
>> tmp_length = strlen (a.arg[dp->arg_index].a.a_string);
>>break;
>
> How did you find this? I thought that valgrind only runs
Hi Ben.
> But running valgrind on test-vasnprintf when USE_SNPRINTF is not
> selected, when the appended patch to test-vasnprintf.c is
> applied, makes it clear that vasnprintf() will read beyond the
> specified precision:
>
> ==3968== Conditional jump or move depends on uninitialised value(s
C89 and C99 are pretty clear that specifying a precision on a %s
directive to printf prevents reading more than that many bytes
from the argument and that in that case no null terminator is
required:
s If no l length modifier is present, the argument shall be
a pointer to the initial e
17 matches
Mail list logo
