Re: [HACKERS] postgresql bug report (fwd)

The Hermit Hacker <scrappy@hub.org> writes:
>     it seems that this problem is a type casting/promotion bug in the
> source. The
>     routine _bt_checkkeys() in backend/access/nbtree/nbtutils.c calls
> int2eq() in
>     backend/utils/adt/int.c via a function pointer
> *fmgr_faddr(&key[0].sk_func). As
>     the type information for int2eq is lost via the function pointer,
> the compiler
>     passes 2 ints, but int2eq expects 2 (preformatted in a 32bit reg)
> int16's.
>     This particular bug goes away, if I for example change int2eq to:

>     bool
>     int2eq(int32 arg1, int32 arg2)
>     {
>             return (int16)arg1 == (int16)arg2;
>     }

Yow.  I can't believe that we haven't seen this failure before on a
variety of platforms.  Calling an ANSI-style function that has char or
short args is undefined behavior if you call it without benefit of a
prototype, because the parameter layout is allowed to be different.
Apparently, fewer compilers exploit that freedom than I would've thought.

Really, *all* of the builtin-function routines ought to take arguments
of type Datum and then do the appropriate Get() macro to extract what
they want from 'em.  That's a depressingly large amount of work, but
at the very least the functions that take bool and int16 have to be
changed...
        regards, tom lane