Re: [RFC] overflow checks optimized away - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC] overflow checks optimized away
Date
Msg-id 31903.1385745679@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC] overflow checks optimized away  (Greg Stark <stark@mit.edu>)
Responses Re: [RFC] overflow checks optimized away  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> b) I'm concerned these checks depend on INT_MIN/MAX and SHRT_MIN/MAX
> which may not be exactly the right length. I'm kind of confused why
> c.h assumes long is 32 bits and short is 16 bits though so I don't
> think I'm making it any worse.

I think it's something we figured we could make configure deal with
if it ever proved necessary; which it hasn't yet.  (In practice, unless
an implementor is going to omit support for these integer widths entirely,
he doesn't have too much choice but to assign them the names "short"
and "int" --- C doesn't provide all that many names he can use.)

> It may be better for us to just define
> our own limits since we know exactly how large we expect these data
> types to be.

Yeah, using INT16_MAX etc would likely be more transparent, if the code
is declaring the variables as int16.

> c) I want to add regression tests that will ensure that the overflow
> checks are all working. So far I haven't been able to catch any being
> optimized away even with -fno-wrapv and -fstrict-overflow.

This does not leave me with a warm feeling about whether this is a useful
exercise.  Maybe you need to try a different compiler?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Todo item: Support amgettuple() in GIN
Next
From: Bruce Momjian
Date:
Subject: Re: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block