On 8/12/20 5:21 PM, Bruno Haible wrote:
Does this sanitizer also apply to implicit conversions in static initializers?
I think not. (But there is always next year's sanitizer. :-)
Thanks for the update; I know this stuff can be a pain.
Paul Eggert wrote:
> My guess is that it matters with picky implementations intended for
> debugging.
> The C standard allows implementations to trap when an out-of-range value is
> converted to a signed integer, and some debugging implementations do that.
> See,
> clang's new
* Bruno Haible:
>> This kind of narrowing initialization is no longer valid C++.
>
> Indeed, GCC 10.2.0 and clang give errors about this code when uses as C++
> code:
>
> $ gcc -Wall -O -S -x c++ foo.c
> foo.c:156:1: error: narrowing conversion of '4294967295' from 'unsigned int'
> to 'int'
On 8/12/20 12:12 PM, Bruno Haible wrote:
why would this matter? This is C code, not C++ code.
My guess is that it matters with picky implementations intended for debugging.
The C standard allows implementations to trap when an out-of-range value is
converted to a signed integer, and some
Florian Weimer wrote:
> gen-uni-tables.c produces types like this:
>
> struct
> {
> int header[1];
> int level1[2];
> short level2[2 << 7];
> /*unsigned*/ int level3[16 << 4];
> }
>
> Why is the unsigned commented out?
I think, at the time the code was written, some K C
gen-uni-tables.c produces types like this:
struct
{
int header[1];
int level1[2];
short level2[2 << 7];
/*unsigned*/ int level3[16 << 4];
}
Why is the unsigned commented out? Some of the constants are so large
that they are treated as unsigned ints.
This kind of narrowing
