>>> On closer look, it's quite obvious: the code added to
>>> ECPGdump_a_type thinks that ECPGt_const is a variable type, and
>>> tries to look up the variable. The straightforward fix is this:
>>> ...
>>> But I wonder if there is a better way to identify variable-kind of
>>> ECPGttypes than list the ones that are not. There's some special
>>> ECPGttypes still missing from the above if-test, like
>>> ECPGt_NO_INDICATOR, but I'm not sure if they can ever be passed to
>>> ECPGdump_a_type. Seems a bit fragile anyway.
>>
>> I agree. How about adding a macro definition explicitely checking
>> for the real
>> variable types?
>
> You'd still have to list them all in the macro, but it would
> definitely be better. The list would then be closer to the enums, in
> the same header file, making it easier to remember to keep it up-to-
> date. (Korry's suggestion of making it a function instead of a macro
> would not have that advantage).
Sure it would... use a switch statement that explicitly handles each
type and include a default case that throws an error (or assertion).
Of course, you have to run into the code to find out that you forgot
to maintain the classification function. A good C compiler will even
spot the problem if you forget to handle one or more enum values in
the switch statement. A macro offers no assurances at all.
-- Korry