Paul Eggert wrote:
> On 10/18/2010 03:25 PM, Bruno Haible wrote:
>> variable-length arrays are valid C and C++ syntax.
>
> Yes, but VLAs are not valid in all contexts. For example,
> one cannot declare a static variable or a structure member
> that is a variable-length array. Whether it makes se
On 10/18/2010 03:25 PM, Bruno Haible wrote:
> variable-length arrays are valid C and C++ syntax.
Yes, but VLAs are not valid in all contexts. For example,
one cannot declare a static variable or a structure member
that is a variable-length array. Whether it makes sense to
support VLAs (with resp
On 10/18/2010 08:34 PM, Gary V. Vaughan wrote:
> I would prefer your "boot" script to be called "bootstrap", and rename
> the current "bootstrap" to something else, maybe "autoconfiscate"
Yes, that would be even better. "autoconfiscate" is a bit long, though.
How about "cobble" instead? "cobble
Hi Paul,
On 19 Oct 2010, at 04:56, Paul Eggert wrote:
> How about another idea: have a very simple bootstrap script. All it
> does is fetch gnulib, and execute gnulib's more-complicated script.
> We could call our new script "boot", say. If this idea works, we
> could copy "boot" to gnulib as we
On 18/10/10 18:29, Paul Eggert wrote:
> On 10/18/10 04:53, Pádraig Brady wrote:
>
>> /* Like sizeof, except that it treats a variable sized array
>>as a pointer rather than determining the size at runtime. */
>> #define CT_SIZEOF(x) (__builtin_constant_p(sizeof x) ? sizeof x: sizeof
>> (void
On 18/10/10 21:15, Ben Pfaff wrote:
> Paul Eggert writes:
>
>> On 10/18/10 04:53, Pádraig Brady wrote:
>>
>>> /* Like sizeof, except that it treats a variable sized array
>>>as a pointer rather than determining the size at runtime. */
>>> #define CT_SIZEOF(x) (__builtin_constant_p(sizeof x)
Hi Paul,
> My kneejerk reaction is that this is way overkill for inttostr.
Part of the macros should then be refactored into a separate file,
so that we can use them also for u16_sprintf and other functions.
> Also, I've had problems with __builtin_object_size not behaving
> as documented for GC
Hi Paolo,
Paolo Bonzini wrote:
> Maybe it is worthwhile however
> to enable the checks for 4.1 with the sole exception of the link-time
> warning. For 4.1 and 4.2, leave out the aliasing of inttostr_chk_warn
> so that it remains undefined and linking fails.
Giving a link error on perfectly va
On 10/17/10 14:34, Joel E. Denny wrote:
> We could just extend the error message to explain the intent. It could
> also explain that --no-bootstrap-sync is useful for trying out bootstrap
> modifications. For longer experiments, it could suggest setting
> bootstrap_sync=false in bootstrap.conf
Hi Jim,
> For the record, it'd help me test things like this if you
> were to post git format-patch output.
I prefer to send "git diff HEAD" output usually. But when there's a new file,
the indentation with a single '+' sign hampers the readability, therefore I
prefer to send them separately.
Fo
Paul Eggert writes:
> On 10/18/10 04:53, Pádraig Brady wrote:
>
>> /* Like sizeof, except that it treats a variable sized array
>>as a pointer rather than determining the size at runtime. */
>> #define CT_SIZEOF(x) (__builtin_constant_p(sizeof x) ? sizeof x: sizeof
>> (void*))
>
> I don't s
On 10/17/10 12:58, Bruno Haible wrote:
> +/* Define auxiliary functions for bounds checking of FUNC.
> + The FUNC_chk_warn function behaves like the FUNC_chk function but emits a
My kneejerk reaction is that this is way overkill for inttostr.
Also, I've had problems with __builtin_object_size no
On 10/18/10 04:53, Pádraig Brady wrote:
> /* Like sizeof, except that it treats a variable sized array
>as a pointer rather than determining the size at runtime. */
> #define CT_SIZEOF(x) (__builtin_constant_p(sizeof x) ? sizeof x: sizeof
> (void*))
I don't see how this would work. If x is
Bruno Haible wrote:
> Jim Meyering wrote:
>> Nice and thorough work. Thanks for covering almost all of the
>> remaining cases.
>
> OK, here's a proposed patch, for inttostr. If that works fine, I'll continue
> with the *sprintf variants in libunistring.
>
>
> 2010-10-17 Jim Meyering
>
Bruno Haible wrote:
> Hi Jim,
>
>> With that, I can enable -Werror in coreutils' gnulib-tests directory.
>
> Only on glibc systems, I hope? On other platforms, there will be lots of other
> warnings that I don't want to deal with individually.
>
> Globally, I don't think it is such a good move. We
On 10/17/2010 03:36 PM, Bruno Haible wrote:
Hi Jim,
With that, I can enable -Werror in coreutils' gnulib-tests directory.
Only on glibc systems, I hope? On other platforms, there will be lots of other
warnings that I don't want to deal with individually.
-Werror is added in coreutils only w
On 10/18/2010 01:53 PM, Pádraig Brady wrote:
On 17/10/10 20:58, Bruno Haible wrote:
+/* When, on glibc systems, -D_FORTIFY_SOURCE=1 or -D_FORTIFY_SOURCE=2 is used,
+ enable extra bounds checking, based on the object bounds analysis done by
+ GCC.
+ The user can disable this bounds checking
On 17/10/10 20:58, Bruno Haible wrote:
> +/* When, on glibc systems, -D_FORTIFY_SOURCE=1 or -D_FORTIFY_SOURCE=2 is
> used,
> + enable extra bounds checking, based on the object bounds analysis done by
> + GCC.
> + The user can disable this bounds checking by defining _GL_NO_FORTIFY.
> + __
19 matches
Mail list logo
