From: | John Regehr <regehr(at)cs(dot)utah(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5592: list of integer undefined behaviors |
Date: | 2010-08-03 22:02:47 |
Message-ID: | 4C589207.5090609@cs.utah.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom, would you be willing to isolate these operations into functions
that could be marked with a "no_overflow_check" attribute? This would
be easy for us to deal with, would survive preprocesing cleanly, and
wouldn't have any performance cost since inliners do a fine job.
John
On 8/3/2010 3:43 PM, Tom Lane wrote:
> John Regehr<regehr(at)cs(dot)utah(dot)edu> writes:
>>> Just to follow up: all the other ones seem to be non-problems.
>
>> Would you folks be willing to specify which arithmetic operations are
>> considered to be safe in the case of overflow? Something simple like an
>> "INTEGER_OVERFLOW_OK" comment at the end of the line of code containing
>> the operation would suffice. This would let me automatically filter out
>> error messages on these lines of code in the future.
>
> That might be doable for individual operations, but I don't think that
> (for example) having to label all the users of RIGHTMOST_ONE() would be
> very maintainable. Is your code capable of tracking back to a macro
> definition?
>
> Also, it would be nicer if we could put the marker comment on an
> adjacent line. If it has to be on the same line then there are
> formatting problems when the code is wide (and pgindent could break it).
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-08-03 22:08:22 | Re: BUG #5592: list of integer undefined behaviors |
Previous Message | Tom Lane | 2010-08-03 21:43:24 | Re: BUG #5592: list of integer undefined behaviors |