On 4 August 2011 07:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <peter@2ndquadrant.com> writes:
>> On 3 August 2011 21:03, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I mean that it's unclear what you'll get if status has a bitpattern
>>> equivalent to a negative integer. If the compiler implements the
>>> comparison as signed, the test will yield TRUE; if unsigned, it's FALSE.
>
>> On compilers on which the enum value is represented as an unsigned
>> int, passing -1 is just the same as doing that with any function with
>> an unsigned int argument for that argument - it will convert to a
>> large unsigned value . So sure, that isolated part of the test's
>> outcome will vary depending on whether or not the compiler opts to
>> represent the enum as signed when it can, but I don't look at it as
>> you do. I simply consider that to be a violation of the enum's
>> contract, or the caller's failure to consider that the enum couldn't
>> represent -1 -- they got what they asked for.
>
> This argument is completely missing the point of the test, which is to
> verify whether or not the caller adhered to the enum's contract. You
> can *not* assume that he did while arguing about whether the test is
> valid or accomplishes its goals.
I did not assume anything about the caller or their trustworthiness.
The whole point of my argument is that passing a negative integer
where the enum is represented as unsigned is just another way of
violating the contract (passing a negative integer where the enum is
represented as signed is another), that is equally well handled by the
test; the whole test though, not the isolated part of it that you
referred to.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
