On 4 August 2011 07:08, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <pe...@2ndquadrant.com> writes: >> On 3 August 2011 21:03, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
