[cfe-dev] Possibly invalid enum tautology warning

[David Blaikie]

On Mon, Aug 8, 2011 at 12:39 PM, Peter Geoghegan <peter at 2ndquadrant.com> wrote:
> On 8 August 2011 20:18, David Blaikie <dblaikie at gmail.com> wrote:
>>> I'd say that it was the most natural way of
>>> expressing the problem; the value of the enum had to be used as an
>>> array subscript, and the enum might well have been unsigned for all we
>>> knew - arbitrary third party code is not to be trusted.
>>
>> Could you explain this in more detail, as it's still not clear to me
>> what postgres was doing, nor how you fixed it.
>
> There was an array that had values that are globally associated with
> each enum constant. Which value in that array corresponds to which
> enum constant is dictated by the enum constants underlying value - we
> explicitly give the first literal in the enum the value 0, just to be
> clear about our intent. Third party client code calls a function to
> find out the value in the array that corresponds to some given enum
> value. However, these clients cannot be trusted to pass a valid enum
> literal, and not pass a value past the end of an array, or a negative
> integer. Also, we cannot assume that the compiler has any particular
> preference as to when it represents enums as signed or unsigned.

Yeah, then I'm with John on this - switching to the canonical
representation (that he deliberately provided support for) of
"first_enum <= value && value <= last_enum" is the right way to
express that.

If there's some other case where testing "enum_value > 0" could be
justified, then perhaps we could talk about that - but without a use
case it doesn't seem worth addressing on such theoretical grounds.

- David