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...

I concur in your Yow.  Lots of changes, and I am surprised we have not
been bitten by this before.  Added to TODO:
Fix function pointer calls to take Datum args for char and int2 args

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026