FAQ
I now getting many compile warnings about ENDIAN-ness. Should we have
these defines nested in #ifndef's?

- ---------------------------------------------------------------------------

gcc2 -I../../../include -I/u/readline -g -Dbsdi -I../.. -I../../port/bsdi -I..
/../../include -c indexvalid.c -o indexvalid.o
In file included from /usr/include/sys/types.h:103,
from /usr/include/sys/time.h:42,
from /usr/include/time.h:81,
from ../../../include/utils/nabstime.h:16,
from ../../../include/access/htup.h:16,
from indexvalid.c:17:
/usr/include/machine/endian.h:52: warning: `LITTLE_ENDIAN' redefined
../../../include/postgres.h:208: warning: this is the location of the previous d
efinition
/usr/include/machine/endian.h:53: warning: `BIG_ENDIAN' redefined
../../../include/postgres.h:209: warning: this is the location of the previous d
efinition
/usr/include/machine/endian.h:54: warning: `PDP_ENDIAN' redefined
../../../include/postgres.h:210: warning: this is the location of the previous d
efinition
==============================================================================<
gcc2 -I../../../include -I/u/readline -g -Dbsdi -I../.. -I../../port/bsdi -I..
/../../include -c scankey.c -o scankey.o
gcc2 -I../../../include -I/u/readline -g -Dbsdi -I../.. -I../../port/bsdi -I..
/../../include -c tupdesc.c -o tupdesc.o
In file included from tupdesc.c:21:
../../../include/postgres.h:208: warning: `LITTLE_ENDIAN' redefined
/usr/include/machine/endian.h:52: warning: this is the location of the previous
definition
../../../include/postgres.h:209: warning: `BIG_ENDIAN' redefined
/usr/include/machine/endian.h:53: warning: this is the location of the previous
definition
../../../include/postgres.h:210: warning: `PDP_ENDIAN' redefined
/usr/include/machine/endian.h:54: warning: this is the location of the previous
definition
ld -r -o SUBSYS.o heaptuple.o heapvalid.o indextuple.o indexvalid.o printtup.o s
cankey.o tupdesc.o
gmake[3]: Leaving directory `/usr/local/src/postgres/postgres95/src/backend/acce
ss/common'
gmake -C gist SUBSYS.o
gmake[3]: Entering directory `/usr/local/src/postgres/postgres95/src/backend/acc
ess/gist'
gcc2 -I../../../include -I/u/readline -g -Dbsdi -I../.. -I../../port/bsdi -I..
/../../include -c gist.c -o gist.o
In file included

- --
Bruce Momjian
maillist@candle.pha.pa.us

------------------------------

Search Discussions

  • Thomas G. Lockhart at Jul 9, 1997 at 4:46 am

    I now getting many compile warnings about ENDIAN-ness. Should we have
    these defines nested in #ifndef's?
    I think we should move the postgres.h endian definitions to <platform>.h
    files where necessary (not needed on most platforms). On my Linux box,
    there is

    #define BIG_ENDIAN 4321
    #define LITTLE_ENDIAN 1234
    #define BYTE_ORDER LITTLE_ENDIAN or ...

    in the existing endian.h.

    So, I propose that these definitions show up in <platform>.h for those
    platforms which don't have BYTE_ORDER and the ENDIAN defines, or in the
    case of AIX that aix.h have an #include <sys/machine.h> (or somewhere,
    I'm not finding it in Gerhart's e-mails but I know it's there).

    btw, on my Linux box endian.h implies that BIG_ENDIAN is a BSDism and is
    not allowed with __STRICT_ANSI__, but that __BIG_ENDIAN is allowed.
    Should we be using the "__BIG" variant in the code rather than "BIG"?

    - Tom

    ------------------------------
  • Bruce Momjian at Jul 9, 1997 at 5:14 am

    I now getting many compile warnings about ENDIAN-ness. Should we have
    these defines nested in #ifndef's?
    I think we should move the postgres.h endian definitions to <platform>.h
    files where necessary (not needed on most platforms). On my Linux box,
    there is

    #define BIG_ENDIAN 4321
    #define LITTLE_ENDIAN 1234
    #define BYTE_ORDER LITTLE_ENDIAN or ...

    in the existing endian.h.

    So, I propose that these definitions show up in <platform>.h for those
    platforms which don't have BYTE_ORDER and the ENDIAN defines, or in the
    case of AIX that aix.h have an #include <sys/machine.h> (or somewhere,
    I'm not finding it in Gerhart's e-mails but I know it's there).
    Let's do that. Would whoever added it please make the change.
    btw, on my Linux box endian.h implies that BIG_ENDIAN is a BSDism and is
    not allowed with __STRICT_ANSI__, but that __BIG_ENDIAN is allowed.
    Should we be using the "__BIG" variant in the code rather than "BIG"?
    No, I think we are OK. the __* is just to insulate the symbol
    environment. BSDI doesn't have the __* defines for these anyway.


    - --
    Bruce Momjian
    maillist@candle.pha.pa.us

    ------------------------------
  • Frank Dana at Jul 9, 1997 at 10:39 am

    With Shakespearian flourish, Bruce Momjian writes:
    I now getting many compile warnings about ENDIAN-ness. Should we have
    these defines nested in #ifndef's?
    That would actually be a really BAD idea, as it means certain parts of
    the code might have a different idea of what BIG_ENDIAN means than other
    parts. (System includes don't follow the same system as the #defines
    in postgres.h.) I caused that problem under AIX when I was trying to
    work around the ENDIAN patches, which is why my initial patches to
    postgres.h didn't work.

    I agree that moving the ENDIAN defines to include/ports/foo.h is a good
    idea. Could whoever is moving them please not include them in aix.h?
    The proper method for dealing with ENDIAN-ness on AIX (both 3.2.5 and 4.1)
    is a simple:

    #include <system/machine.h>

    That should be done in lieu of any HAVE_ENDIAN_H or #ifdef checks.

    -Frank

    - --
    Frank R. Dana, Jr. Senior Associate Programmer
    danaf@ans.net ANS Communications
    (914) 789-5449 100 Clearbrook Rd. Elmsford, NY 10523
    Pager: 800-946-4646 pin# 1420717

    ------------------------------

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 9, '97 at 3:23a
activeJul 9, '97 at 10:39a
posts4
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase