Re: Reliance on undefined behaviour in << operator - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Reliance on undefined behaviour in << operator
Date
Msg-id CA+TgmobjVAXCRsGHzkwzSc8dimapZoivxfp3CY0KZrk2zZ1bVA@mail.gmail.com
Whole thread Raw
In response to Re: Reliance on undefined behaviour in << operator  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Sep 16, 2015 at 3:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Sep 16, 2015 at 3:16 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>>> Our implementation of << is a direct wrapper around the C operator. It
>>> does not check the right-hand side's value.
>>> ... On x64 intel gcc linux it does a rotation but that's
>>> not AFAIK guaranteed by anything, and we should probably not be
>>> relying on this or exposing it at the user level.
>
>> I agree.
>
> As far as I'm concerned, what those operators mean is "whatever your
> compiler makes them mean".  This is hardly the only place where we expose
> platform-dependent behavior --- see also locale dependencies, timezones,
> floating point, yadda yadda --- and I do not find it the most compelling
> place to start reversing that general approach.

No, I don't agree, in this case.  You could say that int32 + int32 is
platform-dependent behavior too, when it overflows.  But we don't say
that.  This case seems more like an overflow condition than it does
like platform-dependent behavior that we should just pass through.

Also, I think it's worth noting that, AFAICT, our users %@#! HATE the
places where we expose platform-dependent behavior.  That's why people
keep proposing ICU for collations, and cursing their fate when Red Hat
rolls out a glibc fix that changes some collation's ordering thus
leaving all their indexes "corrupted".

Of course, we're not in a position to eliminate all of those platform
dependencies, because it would require us to integrate with - or
develop - platform-dependent libraries for all of those things.  And
we don't really have the bandwidth for that, or at least it's not
likely the best use of our time.  But all things being equal, I don't
think the fact that we have platform dependencies that are hard to
eliminate means we should keep around the ones that are easy to
eliminate.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_resetxlog sentences
Next
From: Andres Freund
Date:
Subject: Re: Reliance on undefined behaviour in << operator