On 08/08/18 21:50, Martin Sebor wrote:
>> Sorry, again, but could it be possible that this test case changed
>> with your patch?
>>
>> $ cat w.c
>> const char x[] = { };
>> int main()
>> {
>> __builtin_printf("%ld\n", sizeof(x));
>> return 0;
>> }
>> $ gcc w.c
>> $ ./a.out
>> 1
>>
>> without your patch
>> $ ./a.out
>> 0
>>
>
> Jason/Joseph, is this meant to be accepted? It's rejected with
> a hard error with -Wpedantic but I don't see any tests for it:
>
> warning: ISO C forbids empty initializer braces [-Wpedantic]
> const char x[] = { };
> ^
> error: zero or negative size array ‘b’
> const char x[] = { };
> ^
>
> I'll avoid handling it but I'm not sure I should add a test case
> for it if it's accepted by mistake (and if I should open a bug
> to reject it instead).
>
> The comment above complete_array_type() in c-common.c and
> the code kind of suggest it's on purpose but the odd failure
> mode (hard error with -Wpedantic, silence otherwise) and
> the absence of tests make me wonder.
>
This is also a bit odd:
$ cat w.cc
$ g++ w.cc
w.cc:1:26: error: initializer-string for array of chars is too long
[-fpermissive]
char x[3] = { 1,2,3,4 };
$ cat w1.cc
char x[3] = { 1,2,3,4,5 };
int main()
{
__builtin_printf("%ld\n", sizeof(x));
return 0;
}
$ g++ w.cc
w1.cc:1:28: error: too many initializers for 'char [3]'
char x[3] = { 1,2,3,4,5 };
This suggests, that it might be better to fold the initializer at where
my C/C++ FE patch shortens the string constants?
It would have the advantage, that the array size is already known there.
And it would avoid changing the array size accidentally, because the
decl is already laid out?
What do you think?
Bernd.
