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
