[cfe-dev] Possibly invalid enum tautology warning

Peter Geoghegan peter at 2ndquadrant.com
Mon Aug 8 12:39:41 PDT 2011


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.

> You're saying postgres took a user-defined enum?

No. It was not user-defined. It was simply an enum defined in a
header, included as part of the TU that this function definition is
in, as well as being included in a great deal of client code.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services




More information about the cfe-dev mailing list