gmake of the code without interruption.
There's also some tidy-up of the MAXPATHLEN stuff based on the assumption that
all supported platforms have MAXPATHLEN defined in <sys/param.h>.
(The only unknowns for the above are AIX and IRIX5.)
And now - JMP_BUF again. Is it enough, folks ?
Fixed again:
cc1: warnings being treated as errors
exc.c: In function 'ExcRaise':
exc.c:187: warning: passing arg 1 of 'Longjmp' from incompatible pointer type
gmake[3]: *** [exc.o] Error 1
%ud in a printf format strings instead of just %u.
There were three occurances of this in catalog_utils.c,
two in parser.c and one in rewriteSupport.c in the oid
patch that I submitted and was applied. They won't crash
anything, but the error messages will have a 'd' after the
Oid. Annoying, but none are db-threatening.
Sorry about that folks...I'll be more careful in the future...
Darren King
As an example I sent a bug-report on 26 Nov to tell that the fix included
below is necessary to compile pg95-current on Ultrix with Digital's
standard C compiler c89. In fact I think that this fix is needed
for any C compiler sticking very close the standard, see my discussion
in the original bug report.
Erik Bertelsen
cc1: warnings being treated as errors
datum.c: In function `DatumGetSize':
datum.c:57: warning: unsigned value >= 0 is always 1
gmake[3]: *** [datum.o] Error 1
There was:
if (byVal) {
if (len >= 0 && len <= sizeof(Datum)) {
but len has type Size (unsigned int) and so now there is:
if (byVal) {
if (len <= sizeof(Datum)) {
cc1: warnings being treated as errors
exc.c: In function 'ExcRaise':
exc.c:186: warning: passing arg 1 of 'Longjmp' from incompatible pointer type
gmake[3]: *** [exc.o] Error 1
Now we have:
#if defined (JMP_BUF)
longjmp(efp->context, 1);
#else
siglongjmp(efp->context, 1);
#endif
cc1: warnings being treated as errors
transsup.c: In function `TransBlockGetLastTransactionIdStatus':
transsup.c:122: warning: unsigned value >= 0 is always 1
gmake[3]: *** [transsup.o] Error 1
...
(old _bt_compare always returned >= 0 while comparing with P_HIKEY
on root page - it breaks root page when _bt_insertonpg tries insert
new minimal key into root page).
2. Fixed bug concerns "empty" pages: non-rightmost pages with only P_HIKEY
present on it. Such pages appear after vacuum.
