Should GCC warn when __LINE__ is treated as %u %d %i?

[Jonny Grant]

On 19/02/2019 15:21, Martin Sebor wrote:
> On 2/19/19 4:27 AM, Jonny Grant wrote:
>>
>>
>> On 18/02/2019 22:03, Martin Sebor wrote:
>>> On 2/17/19 7:12 AM, Jonny Grant wrote:
>>>> Hello
>>>>
>>>> **Please keep my email address in any replies.
>>>>
>>>>
>>>> 1) should this not give type conversion warnings?
>>>>
>>>> printf("lineoutput %d:%u:%i\n", __LINE__, __LINE__, __LINE__);
>>>>
>>>> 2) Should __LINE__ expand as an 'int', or 'unsigned int'?
>>>>
>>>> Had expected line 9 to expand as '9U', but -save-temps shows it ends 
>>>> up as:
>>>>
>>>> printf("lineoutput %d:%u:%i\n", 9, 9, 9);
>>>
>>> The bigger problem with __LINE__ is that it need not expand to int
>>> at all, such as in the following:
>>>
>>> $ cat u.c && gcc -O2 -S -Wall -Wextra u.c
>>> #line 2147483647
>>>
>>> void f (void)
>>> {
>>> Â Â  __builtin_printf ("%i", __LINE__);
>>> }
>>> u.c: In function ‘f’:
>>> u.c:-2147483646:21: warning: format ‘%i’ expects argument of type 
>>> ‘int’, but argument 2 has type ‘long int’ [-Wformat=]
>>>
>>> Notice how the line number in the message doesn't correspond to
>>> the sum of 2147483647 and 3 (the offset from the #line directive).
>>>
>>> Martin
>>
>> Good point. Looks like a compiler limitation. Although I wonder how 
>> many files really have that many lines, but anyway...
>>
>> GCC could store the line number as a 'long int', then can display line 
>> numbers up to 2^63
>>
>> u.c: In function ‘f’:
>> u.c:2147483650:21: warning: format ‘%i’ expects argument of type 
>> ‘int’, but argument 2 has type ‘long int’ [-Wformat=]
>>
>> I can file a on gcc.gnu.org bugzilla, or would you prefer to file 
>> yourself?
> 
> You're right that having that many physical lines is very unlikely.
> The only way for this to be noticed that I can think of is in
> conjunction with the #line directive explicitly setting very large
> numbers (perhaps in generated code).  I'm not sure it's worth growing
> the GCC internal tree node by 4 bytes but detecting the overflow and
> issuing a diagnostic, maybe even an error, rather than allowing line
> numbers to start to decrease, would be cheap and an improvement.
> Either way, if you agree this is worth at least making a record of
> in Bugzilla, please go ahead.
> 
> Martin

Ok, I filled it. as it causes an ICE with a bigger number.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410

Would be nice if the actual line number was retained along with the 
#line set number. eg the ICE error has the wrong line number (hehe) ... 
it could show the actual line number

Cheers, Jonny