From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GCC 7 warnings |
Date: | 2017-04-12 15:31:09 |
Message-ID: | 6997.1492011069@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 4/12/17 00:12, Tom Lane wrote:
>> Now a human can see that saved_timeval.tv_usec must be 0..999999, so
>> that the %d format item must always emit exactly 3 characters, which
>> means that really 5 bytes would be enough. I wouldn't expect a
>> compiler to know that, but if it's making a generic assumption about
>> the worst-case width of %d, shouldn't it conclude that we might need
>> as many as 13 bytes for the buffer? Why does msbuf[10] satisfy it
>> if msbuf[8] doesn't?
> Because the /1000 takes off three digits?
Huh ... I would not really have expected it to figure that out, but
this makes it pretty clear that it did:
> test.c:11:15: note: directive argument in the range [-2147483, 2147483]
> (This is with -O2. With -O0 it only asks for 5 bytes.)
But that reinforces my suspicion that the intelligence brought to bear
here will be variable. I'd still go for msbuf[16]; it's not like
anybody's going to notice the extra stack consumption.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-04-12 15:32:02 | Re: snapbuild woes |
Previous Message | Tom Lane | 2017-04-12 15:26:41 | Re: the need to finish |