Hi,
On 2018-02-14 17:36:38 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I can't convince any of my compilers to actual emit warnings in this
> > case, so we'll have to see whether prairiedog like this...
>
> Per my results yesterday, locust and coypu were also complaining;
> one of them mi
Andres Freund writes:
>> Yea, that works for me. I wonder if we should choose an absurd sentinel
>> value to prevent code from relying on one? 0xbeef or such. Unless
>> somebody protests soon-ish I'll make it so.
> Pushed that way (with 0x5EED as the value, seems more appropriate ;)).
LGTM,
On 2017-12-29 12:21:54 -0800, Andres Freund wrote:
> On 2017-12-27 17:59:26 -0500, Tom Lane wrote:
> > #if defined(HAVE__BUILTIN_OP_OVERFLOW)
> > return __builtin_add_overflow(a, b, result);
> > #else
> > int32 res = (int32) a + (int32) b;
> >
> > if (res > PG_INT16_MAX ||
On 2017-12-27 17:59:26 -0500, Tom Lane wrote:
> [ back from Christmas break ]
>
> Andres Freund writes:
> > On December 22, 2017 7:52:54 PM GMT+01:00, Tom Lane
> > wrote:
> >> I will not accept an implementation that spews compiler warnings
> >> all over the place, which is what this one is doi
On Sat, Dec 30, 2017 at 8:43 AM, Andres Freund wrote:
> On 2017-12-29 23:06:10 +1300, Thomas Munro wrote:
>> On Wed, Dec 13, 2017 at 2:01 PM, Andres Freund wrote:
>> > Use new overflow aware integer operations.
>>
>> frogmouth seems to have crashed in the vicinity of various number
>> processing
On 2017-12-29 23:06:10 +1300, Thomas Munro wrote:
> On Wed, Dec 13, 2017 at 2:01 PM, Andres Freund wrote:
> > Use new overflow aware integer operations.
>
> frogmouth seems to have crashed in the vicinity of various number
> processing tests -- could this commit be responsible? A wild guess as
>
On Wed, Dec 13, 2017 at 2:01 PM, Andres Freund wrote:
> Use new overflow aware integer operations.
frogmouth seems to have crashed in the vicinity of various number
processing tests -- could this commit be responsible? A wild guess as
there isn't much to go on in the build log:
https://buildfar
[ back from Christmas break ]
Andres Freund writes:
> On December 22, 2017 7:52:54 PM GMT+01:00, Tom Lane
> wrote:
>> I will not accept an implementation that spews compiler warnings
>> all over the place, which is what this one is doing. Please fix that,
>> or else I will.
> Are you seriousl
On December 22, 2017 7:52:54 PM GMT+01:00, Tom Lane wrote:
>Andres Freund writes:
>> On 2017-12-22 11:00:54 -0500, Tom Lane wrote:
>>> I do not think it is reasonable for these functions to not set the
>>> output variable at all in the overflow case; it is not their job
>>> to opine on whether
Andres Freund writes:
> On 2017-12-22 11:00:54 -0500, Tom Lane wrote:
>> I do not think it is reasonable for these functions to not set the
>> output variable at all in the overflow case; it is not their job
>> to opine on whether the caller may use the result.
> I don't agree. Please note that t
Hi,
On 2017-12-22 11:00:54 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Use new overflow aware integer operations.
>
> I just tried to compile manually on prairiedog for the first time since
> this went in, and noticed that it now produces a boatload of warnings
> like
>
> int.c: In funct
Andres Freund writes:
> Use new overflow aware integer operations.
I just tried to compile manually on prairiedog for the first time since
this went in, and noticed that it now produces a boatload of warnings
like
int.c: In function 'int2pl':
int.c:735: warning: 'result' may be used uninitialize
David Rowley writes:
> I notice it's caused a small warning in compilers that don't
> understand about elog(ERROR) and ereport(ERROR) not returning.
Wups, I noticed this independently and fixed it before reading your
message. Sorry about failing to credit you in the commit log.
On 13 December 2017 at 14:01, Andres Freund wrote:
> Use new overflow aware integer operations.
Thanks for making this happen.
I notice it's caused a small warning in compilers that don't
understand about elog(ERROR) and ereport(ERROR) not returning.
This can be seen on bowerbird's compile log
14 matches
Mail list logo
