Re: BUG #5592: list of integer undefined behaviors

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
>

In response to

Responses

Browse pgsql-bugs by date

  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