From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | The Hermit Hacker <scrappy(at)hub(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, Jack Howarth <howarth(at)nitro(dot)med(dot)uc(dot)edu> |
Subject: | Re: [HACKERS] postgresql bug report (fwd) |
Date: | 1999-05-14 21:46:23 |
Message-ID: | 16224.926718383@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The Hermit Hacker <scrappy(at)hub(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-05-14 21:51:09 | Re: [HACKERS] rules regression test |
Previous Message | Oleg Bartunov | 1999-05-14 20:37:26 | 6.5 cvs: problem with includes in src/interfaces/libpq++/ |