Re: postgresql

> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Fri, 14 May 1999 18:54:59 +0200
>
> Hi,
>
> 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;
> }
>
> This moves away the type casting/promotion "work" from caller to the callee and
> is probably the right thing to do for functions used via function pointers.
>
> As there are quite a lot changes to do and check, it would be best to forward
> this to the postgresql maintainers.

It may help to prototype the function to match the way it is called:

int int2eq();

bool int2eq(int16 a, int16 b)
{
  return a == b;
}

and then gcc will say something like:

z.c:6: conflicting types for `int2eq'
z.c:6: An argument type that has a default promotion
z.c:6: can't match an empty parameter name list declaration.
z.c:3: previous declaration of `int2eq'

which is correct.  Of course, to actually make the thing compile you
then need to change the 'int16' to 'int'; but the prototype warns the
compiler of what's going on, so it may help avoid other problems with
the trickiness that PostgreSQL uses.

Otherwise, it's also acceptable to insert an appropriate cast whenever
such functions are used, so you'd write (*(int
*(int16,int16))fmgr_addr(xxx))(xxx) for some 'xxx'.  This has the
advantage that you won't accidentally pass a 'long' when the routine
expects an 'int'.  Of course, you'd use a typedef not just put
the type in directly.

I've added the postgresql main mailing list so that they know why
things don't work on powerpc.  I expect they will have similar
problems on alpha and/or sparc.

--
Geoffrey Keating <geoffk@ozemail.com.au>