FAQ
Hi to all endians ;-)

Maybe my mail was lost again, I'll repost it here into the list only.

Best regards
Gerhard

PS: I always suggested to use NEVER *ENDIAN #defines.

- ---------- Forwarded message ----------
Date: Tue, 8 Jul 1997 12:17:15 +0200 (MET DST)
From: Gerhard Reithofer <gerhardr@tech-edv.co.at>
To: "Thomas G. Lockhart" <Thomas.Lockhart@jpl.nasa.gov>
Cc: t-ishii@sra.co.jp, Bruce Momjian <maillist@candle.pha.pa.us>,
hackers@postgreSQL.org
Subject: Re: [HACKERS] The never ending ENDIAN story...

Hi to all Hackers,
On Mon, 7 Jul 1997, Thomas G. Lockhart wrote:

Tatsuo, apparently the only remaining question regarding the endian
patches is where to place the endian definitions if endian.h is not
available. You placed the definitions in postgres.h, but expressed
reservations, and Gerhard suggests that perhaps individual <platform>.h
files would be better (his machine had trouble with postgres.h as-is).

How many of your test platforms actually required the BYTE_ORDER or
BIG/LITTLE_ENDIAN definitions? There is at least one platform (AIX,
*sigh*) which provides the definitions but does not have an endian.h,
and which will need an extra #include to find it (very platform
specific, so should go in aix.h?). If there are only one or two other
platforms which do not have endian.h, then it seems that the
<platform>.h file might be the best place to locate this for the v6.1
patch release.

What is your opinion? Everyone??
=======================================================================
Which processors?

IMHO most processor types use big endian representation. E.g. the old
IBM/RS6000, the new Power PC's, Sun Sparc, all 68x processors
(Motorola)... All little endians, that I know are Intel 86x and DEC Alpha
AXP's.
========================================================================
Where to implement?

There's not place for implementation. It's usually done by the system.
For network communication the include file <netinet/in.h> defines the
stuff. For type definitions you should include <unistd.h> before
<netinet/in.h> (may be obsolete on some systems?).

The programmer should NOT deal with endians and all #define *ENDIAN*
should be removed from the code.

A little test program shows that:
==============================================================
#include <unistd.h>
#include <netinet/in.h>

#define NUMBER 0x1234
#define LUMBER 0xDeadBeef

main()
{
unsigned short int ns;
unsigned long int nl;
system("echo Machine type is `uname`.");
ns=htons(NUMBER);
printf("The short number %x is in the net %x.\n",NUMBER,ns);
nl=htonl(LUMBER);
printf("The long number %lx is in the net %lx.\n",LUMBER,nl);
}
===================================================================

gerhardr@aix530:/home/gerhardr > ./a.out
Machine type is AIX.
The short number 1234 is in the net 1234.
The long number deadbeef is in the net deadbeef.

gerhardr@server:/home/gerhardr > ./a.out
Machine type is Linux.
The short number 1234 is in the net 3412.
The long number deadbeef is in the net efbeadde.

... it's an Intel - a PPC Linux should react like in the 1st example.

Best regards,
Gerhard

+------------------+ +--- gerhardr@tech-edv.co.at ----+
T.B.Reithofer \ Gerhard | Technical Sofware Developement |
Staatsbahnstr. 100 \ Reithofer | CAD/CAM/CAE/CAQ/CAP +----------+
A-2136 Laa/Thaya +----------+ Mechanical CAD +----+
Tel +43-2522/8726, Fax +43-2522/87268 +---------+
+---------------------------------------+

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

Search Discussions

  • Frank Dana at Jul 9, 1997 at 10:52 am

    With Shakespearian flourish, Gerhard Reithofer writes:
    Hi to all endians ;-)

    Maybe my mail was lost again, I'll repost it here into the list only.
    No, we got it. I just didn't take the time to write my dissenting
    opinion piece yet. Fortunately, I'm watching field upgrades today
    and have some spare cycles. <grin,evil>
    PS: I always suggested to use NEVER *ENDIAN #defines.
    And I don't see how that could possibly by workable. What do we do
    when the system hits a machine that doesn't properly handle ENDIAN-ness?

    I agree, if PostgreSQL is just running on a single machine, you can
    ignore ENDIAN issues and allow the backend to store data in whatever
    ENDIANness is used by the system. But PostgreSQL is a networked
    database that needs to be able to intercommunicate between machines
    using different ENDIANness. If the local OS doesn't properly handle
    ENDIAN information, it has to figure out some method for getting the
    bytes right so that machines can talk to each other.

    I personally agree with Bruce's thought that PostgreSQL should just take
    the intellectual high ground and assume all OS's are stupid. Just use a
    quick check script, figure out local ENDIANness for ourselves, and use
    that information instead of local defines (if any).

    -Frank

    P.S> In the meantime, moving the ENDIAN work to <port>.h means we
    can properly handle the cases for all OS's that work correctly.

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

    ------------------------------
  • Gerhard Reithofer at Jul 9, 1997 at 2:01 pm

    On Wed, 9 Jul 1997, Frank Dana wrote:

    With Shakespearian flourish, Gerhard Reithofer writes:
    Hi to all endians ;-)
    ... CUT ...
    PS: I always suggested to use NEVER *ENDIAN #defines.
    And I don't see how that could possibly by workable. What do we do
    when the system hits a machine that doesn't properly handle ENDIAN-ness?
    If the system DOES NOT the correct conversion, you are unable to
    communicate over the network. You couldn't use any NFS, Telnet, FTP
    service between different platforms, if they would transfer data in
    different manner.
    I agree, if PostgreSQL is just running on a single machine, you can
    ignore ENDIAN issues and allow the backend to store data in whatever
    ENDIANness is used by the system. But PostgreSQL is a networked
    database that needs to be able to intercommunicate between machines
    using different ENDIANness. If the local OS doesn't properly handle
    ENDIAN information, it has to figure out some method for getting the
    bytes right so that machines can talk to each other.
    That's absolutely my opinion too - but as above ... it's the OS-designer's
    work to turn it into the correct byte order.
    IMHO the client should never see the physical database structure and the
    server should not care about the clients internal representation. Just the
    way how the Octets (8-bit data chunk) smash through the net MUST be
    always the same.
    I personally agree with Bruce's thought that PostgreSQL should just take
    the intellectual high ground and assume all OS's are stupid. Just use a
    quick check script, figure out local ENDIANness for ourselves, and use
    that information instead of local defines (if any).
    I agree too, when using OS-specific features, like a dynamic loading
    mechanism (it's too the AIX which caused much work - poor Darren) - but
    the communication MUST be the same - else I would call it an
    operatiog system error and it's no wise desicion to write a program based
    on an erroneous design.

    These thoughts are based on the usage of transferring
    short integers - pqPutShort,pqGetShort
    long integers - pqGetLong,pqGetLong
    char* string data - pqPutString
    fixed byte array - pqPutNBytes

    When transferring other data (e. g. reals) in an machine internal
    representation, this discussion will start up again.

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

    It's again just my personal oppinion and I'm sure, that you will solve
    the problem and it will be great solution, transparent and simple.

    Cheers and thanks to all
    Gerhard

    +------------------+ +--- gerhardr@tech-edv.co.at ----+
    T.B.Reithofer \ Gerhard | Technical Sofware Developement |
    Staatsbahnstr. 100 \ Reithofer | CAD/CAM/CAE/CAQ/CAP +----------+
    A-2136 Laa/Thaya +----------+ Mechanical CAD +----+
    Tel +43-2522/8726, Fax +43-2522/87268 +---------+
    +---------------------------------------+

    ------------------------------
  • Thomas G. Lockhart at Jul 9, 1997 at 5:16 pm
    This is a multi-part message in MIME format.

    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit

    There are two different problems being discussed in this thread:
    1) the best patches to apply to v6.1 to preserve v6.0 byte ordering
    2) the best general solution to network byte ordering

    This thread started with (1), and IMHO the only thing holding up the
    v6.1 patch release is (2), which is not relevant to the patches.

    For the patch release, we would like the minimum number of changes to
    minimize the risk that known working ports become broken.

    OK, so to get the patch release rolling I would suggest the following
    changes:
    a) remove the endian #defines in postgres.h
    b) add a line #include <sys/machine.h> into aix.h,
    per Frank Dana's info
    c) add the endian #defines to the following <port>.h files,
    surrounded by #ifndefs:

    (grepping for BYTE_ORDER in include/port/*)
    dgux.h: #define BYTE_ORDER BIG_ENDIAN
    i386_solaris.h: #define BYTE_ORDER LITTLE_ENDIAN
    sparc_solaris.h:#define BYTE_ORDER BIG_ENDIAN
    sunos4.h: #define BYTE_ORDER BIG_ENDIAN
    ultrix4.h: #define BYTE_ORDER LITTLE_ENDIAN
    univel.h: #define BYTE_ORDER LITTLE_ENDIAN

    Are these changes sufficient to fix all current troubles with v6.1
    endian issues? We should have these specific changes tested by an AIX
    installation. Are there additional changes needed for HP/UX??

    If these changes are agreeable, then I will commit changes to the source
    tree. It would help if those testing these changes would send any extra
    changes to ensure that nothing is left out. Tatsuo and Gerhard, could
    you try these on your mix of platforms?

    - Tom

    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii; name="aix.h.patch"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline; filename="aix.h.patch"

    *** ../src/include/port/aix.h.orig Sun Jun 1 16:01:36 1997
    - --- ../src/include/port/aix.h Wed Jul 9 16:21:38 1997
    ***************
    *** 5,7 ****
    - --- 5,8 ----
    # define HAVE_ANSI_CPP
    # define HAS_TEST_AND_SET
    typedef unsigned int slock_t;
    + #include <sys/machine.h> /* ENDIAN definitions for network communication */

    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii; name="dgux.h.patch"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline; filename="dgux.h.patch"

    *** ../src/include/port/dgux.h.orig Fri Jun 6 04:01:49 1997
    - --- ../src/include/port/dgux.h Wed Jul 9 17:03:22 1997
    ***************
    *** 1,7 ****
    #define LINUX_ELF
    #define USE_POSIX_SIGNALS
    #define USE_POSIX_TIME
    ! #ifndef BYTE_ORDER
    ! # define BYTE_ORDER BIG_ENDIAN
    #endif

    - --- 1,17 ----
    #define LINUX_ELF
    #define USE_POSIX_SIGNALS
    #define USE_POSIX_TIME
    !
    ! #ifndef BIG_ENDIAN
    ! #define BIG_ENDIAN 4321
    ! #endif
    ! #ifndef LITTLE_ENDIAN
    ! #define LITTLE_ENDIAN 1234
    ! #endif
    ! #ifndef PDP_ENDIAN
    ! #define PDP_ENDIAN 3412
    ! #endif
    ! #ifndef BYTE_ORDER
    ! #define BYTE_ORDER BIG_ENDIAN
    #endif


    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii; name="i386_solaris.h.patch"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline; filename="i386_solaris.h.patch"

    *** ../src/include/port/i386_solaris.h.orig Sat Apr 12 10:21:45 1997
    - --- ../src/include/port/i386_solaris.h Wed Jul 9 16:58:46 1997
    ***************
    *** 7,14 ****

    #include <sys/isa_defs.h>

    ! #ifndef BYTE_ORDER
    ! #define BYTE_ORDER LITTLE_ENDIAN
    #endif

    #ifndef NAN
    - --- 7,23 ----

    #include <sys/isa_defs.h>

    ! #ifndef BIG_ENDIAN
    ! #define BIG_ENDIAN 4321
    ! #endif
    ! #ifndef LITTLE_ENDIAN
    ! #define LITTLE_ENDIAN 1234
    ! #endif
    ! #ifndef PDP_ENDIAN
    ! #define PDP_ENDIAN 3412
    ! #endif
    ! #ifndef BYTE_ORDER
    ! #define BYTE_ORDER LITTLE_ENDIAN
    #endif

    #ifndef NAN

    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii; name="sparc_solaris.h.patch"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline; filename="sparc_solaris.h.patch"

    *** ../src/include/port/sparc_solaris.h.orig Sat Apr 12 10:21:50 1997
    - --- ../src/include/port/sparc_solaris.h Wed Jul 9 17:00:07 1997
    ***************
    *** 5,10 ****
    - --- 5,19 ----
    # define HAS_TEST_AND_SET
    typedef unsigned char slock_t;

    + #ifndef BIG_ENDIAN
    + #define BIG_ENDIAN 4321
    + #endif
    + #ifndef LITTLE_ENDIAN
    + #define LITTLE_ENDIAN 1234
    + #endif
    + #ifndef PDP_ENDIAN
    + #define PDP_ENDIAN 3412
    + #endif
    #ifndef BYTE_ORDER
    #define BYTE_ORDER BIG_ENDIAN
    #endif

    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii; name="sunos4.h.patch"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline; filename="sunos4.h.patch"

    *** ../src/include/port/sunos4.h.orig Thu Apr 24 22:01:59 1997
    - --- ../src/include/port/sunos4.h Wed Jul 9 17:01:46 1997
    ***************
    *** 1,5 ****
    #define USE_POSIX_TIME
    - - #ifndef BYTE_ORDER
    - - # define BYTE_ORDER BIG_ENDIAN
    - - #endif

    - --- 1,14 ----
    #define USE_POSIX_TIME

    + #ifndef BIG_ENDIAN
    + #define BIG_ENDIAN 4321
    + #endif
    + #ifndef LITTLE_ENDIAN
    + #define LITTLE_ENDIAN 1234
    + #endif
    + #ifndef PDP_ENDIAN
    + #define PDP_ENDIAN 3412
    + #endif
    + #ifndef BYTE_ORDER
    + #define BYTE_ORDER BIG_ENDIAN
    + #endif

    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii; name="ultrix4.h.patch"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline; filename="ultrix4.h.patch"

    *** ../src/include/port/ultrix4.h.orig Wed May 7 04:01:39 1997
    - --- ../src/include/port/ultrix4.h Wed Jul 9 17:04:30 1997
    ***************
    *** 1,6 ****
    - --- 1,15 ----
    # define USE_POSIX_TIME
    # define NEED_STRDUP

    + #ifndef BIG_ENDIAN
    + #define BIG_ENDIAN 4321
    + #endif
    + #ifndef LITTLE_ENDIAN
    + #define LITTLE_ENDIAN 1234
    + #endif
    + #ifndef PDP_ENDIAN
    + #define PDP_ENDIAN 3412
    + #endif
    #ifndef BYTE_ORDER
    #define BYTE_ORDER LITTLE_ENDIAN
    #endif

    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii; name="univel.h.patch"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline; filename="univel.h.patch"

    *** ../src/include/port/univel.h.orig Sat Apr 12 10:21:54 1997
    - --- ../src/include/port/univel.h Wed Jul 9 17:05:54 1997
    ***************
    *** 13,18 ****
    - --- 13,27 ----
    extern int strcasecmp(char *s1,char *s2);
    extern int gethostname(char *name,int namelen);

    + #ifndef BIG_ENDIAN
    + #define BIG_ENDIAN 4321
    + #endif
    + #ifndef LITTLE_ENDIAN
    + #define LITTLE_ENDIAN 1234
    + #endif
    + #ifndef PDP_ENDIAN
    + #define PDP_ENDIAN 3412
    + #endif
    #ifndef BYTE_ORDER
    #define BYTE_ORDER LITTLE_ENDIAN
    #endif

    - --------------62D15EAA7C9C020D3826EB14
    Content-Type: text/plain; charset=us-ascii; name="postgres.h.patch"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline; filename="postgres.h.patch"

    *** ../src/include/postgres.h.orig Tue Jul 1 04:01:30 1997
    - --- ../src/include/postgres.h Wed Jul 9 17:09:59 1997
    ***************
    *** 204,213 ****
    #define STATUS_BAD_PACKET (-7)
    #define STATUS_FOUND (1)

    - - #if !defined(HAVE_ENDIAN_H)
    - - # define LITTLE_ENDIAN 1
    - - # define BIG_ENDIAN 2
    - - # define PDP_ENDIAN 3
    - - #endif
    - -
    #endif /* POSTGRES_H */
    - --- 204,207 ----

    - --------------62D15EAA7C9C020D3826EB14--

    ------------------------------
  • Bruce Momjian at Jul 9, 1997 at 6:22 pm

    There are two different problems being discussed in this thread:
    1) the best patches to apply to v6.1 to preserve v6.0 byte ordering
    2) the best general solution to network byte ordering
    Yea, we are moving forward.
    This thread started with (1), and IMHO the only thing holding up the
    v6.1 patch release is (2), which is not relevant to the patches.

    For the patch release, we would like the minimum number of changes to
    minimize the risk that known working ports become broken.

    OK, so to get the patch release rolling I would suggest the following
    changes:
    a) remove the endian #defines in postgres.h
    b) add a line #include <sys/machine.h> into aix.h,
    per Frank Dana's info
    c) add the endian #defines to the following <port>.h files,
    surrounded by #ifndefs:

    (grepping for BYTE_ORDER in include/port/*)
    dgux.h: #define BYTE_ORDER BIG_ENDIAN
    i386_solaris.h: #define BYTE_ORDER LITTLE_ENDIAN
    sparc_solaris.h:#define BYTE_ORDER BIG_ENDIAN
    sunos4.h: #define BYTE_ORDER BIG_ENDIAN
    ultrix4.h: #define BYTE_ORDER LITTLE_ENDIAN
    univel.h: #define BYTE_ORDER LITTLE_ENDIAN
    I assume these are the platforms that don't define BYTE_ORDER.
    Are these changes sufficient to fix all current troubles with v6.1
    endian issues? We should have these specific changes tested by an AIX
    installation. Are there additional changes needed for HP/UX??

    If these changes are agreeable, then I will commit changes to the source
    tree. It would help if those testing these changes would send any extra
    changes to ensure that nothing is left out. Tatsuo and Gerhard, could
    you try these on your mix of platforms?
    - --
    Bruce Momjian
    maillist@candle.pha.pa.us

    ------------------------------
  • Gerhard Reithofer at Jul 10, 1997 at 1:30 pm
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.
    Send mail to mime@docserver.cac.washington.edu for more info.

    - ---1463809280-1392365030-868541423=:7789
    Content-Type: TEXT/PLAIN; charset=US-ASCII

    On Wed, 9 Jul 1997, Thomas G. Lockhart wrote:

    Hi Hackers, hi Tom,
    There are two different problems being discussed in this thread:
    1) the best patches to apply to v6.1 to preserve v6.0 byte ordering
    2) the best general solution to network byte ordering

    This thread started with (1), and IMHO the only thing holding up the
    v6.1 patch release is (2), which is not relevant to the patches.

    For the patch release, we would like the minimum number of changes to
    minimize the risk that known working ports become broken.

    OK, so to get the patch release rolling I would suggest the following
    changes:
    a) remove the endian #defines in postgres.h
    b) add a line #include <sys/machine.h> into aix.h,
    per Frank Dana's info
    c) add the endian #defines to the following <port>.h files,
    surrounded by #ifndefs:

    (grepping for BYTE_ORDER in include/port/*)
    dgux.h: #define BYTE_ORDER BIG_ENDIAN
    i386_solaris.h: #define BYTE_ORDER LITTLE_ENDIAN
    sparc_solaris.h:#define BYTE_ORDER BIG_ENDIAN
    sunos4.h: #define BYTE_ORDER BIG_ENDIAN
    ultrix4.h: #define BYTE_ORDER LITTLE_ENDIAN
    univel.h: #define BYTE_ORDER LITTLE_ENDIAN

    Are these changes sufficient to fix all current troubles with v6.1
    endian issues? We should have these specific changes tested by an AIX
    installation. Are there additional changes needed for HP/UX??

    If these changes are agreeable, then I will commit changes to the source
    tree. It would help if those testing these changes would send any extra
    changes to ensure that nothing is left out. Tatsuo and Gerhard, could
    you try these on your mix of platforms?

    - Tom
    I'm a bit confused, what to test!

    1. We have a V6.1, which can talk only to same endian platform machines.
    Is that correct?

    2. V6.1p1 can talk to any V6.1p1 machine, but is strict using little
    endian byte order, which is reversed the the "standard network byte
    order". That's V6.1 with the patches "postgresql-v6.1-chngs-p1.tar".
    Is that correct?

    This version I've tested with patches:
    aix.h.patch
    postgres.h.patch
    applied, on the platforms Linux/Intel and AIX 4.1.

    For testing AIX 3.x we have to wait for Darren (who wanted to be back at
    the 14th - if I remember correct).

    Both versions worked in all Server/Client combinations (Linix/Linux,
    AIX/AIX, AIX/Linux, Linux/AIX) - as I expected.

    3. V6.2 which should use "standard network byte order", which is intended
    to get implemented, but there's no code for that yet.
    Is that correct?

    ======================================================================
    BTW in our office the attached V6.1 patch "pqcomprim.c.patch" has been
    applied. This leads to to the situation that Linux/AIX work in all
    combinations using the "standard network byte order".

    Best regards,
    Gerhard

    PS: Hope that I tested the correct combinations - Tom?

    +------------------+ +--- gerhardr@tech-edv.co.at ----+
    T.B.Reithofer \ Gerhard | Technical Sofware Developement |
    Staatsbahnstr. 100 \ Reithofer | CAD/CAM/CAE/CAQ/CAP +----------+
    A-2136 Laa/Thaya +----------+ Mechanical CAD +----+
    Tel +43-2522/8726, Fax +43-2522/87268 +---------+
    +---------------------------------------+

    - ---1463809280-1392365030-868541423=:7789
    Content-Type: TEXT/PLAIN; charset=US-ASCII; name="pqcomprim.c.patch"
    Content-Transfer-Encoding: BASE64
    Content-ID: <Pine.LNX.3.95.970710153023.7789B@server>
    Content-Description: pqcomprim.c.patch

    LS0tIGJhY2tlbmQvbGlicHEvcHFjb21wcmltLmMub3JpZwlXZWQgSnVuIDEx
    IDA2OjAwOjMyIDE5OTcNCisrKyBiYWNrZW5kL2xpYnBxL3BxY29tcHJpbS5j
    CVRodSBKdWwgMTAgMTQ6NTY6MjEgMTk5Nw0KQEAgLTQsNDggKzQsMTkgQEAN
    CiAjaW5jbHVkZSAicG9zdGdyZXMuaCINCiAjaW5jbHVkZSAibGlicHEvcHFj
    b21tLmgiDQogDQotI2lmZGVmICAgICAgICBIQVZFX0VORElBTl9IDQotIyAg
    aW5jbHVkZSAgICA8ZW5kaWFuLmg+DQotI2VuZGlmDQotDQotDQogLyogLS0t
    LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
    LS0tLS0tLS0tLS0tLS0tLS0tLS0tICovDQotLyogSXMgdGhlIG90aGVyIHdh
    eSBhcm91bmQgdGhhbiBzeXN0ZW0gbnRvaC9odG9uLCBzbyB3ZSByb2xsIG91
    ciBvd24NCi0JaGVyZSAqLw0KLQkNCi0jaWZuZGVmCQlCWVRFX09SREVSDQot
    I2Vycm9yIEJZVEVfT1JERVIgbXVzdCBiZSBkZWZpbmVkIGFzIExJVFRMRV9F
    TkRJQU4sIEJJR19FTkRJQU4gb3IgUERQX0VORElBTg0KLSNlbmRpZg0KLQ0K
    LSNpZiBCWVRFX09SREVSID09IExJVFRMRV9FTkRJQU4NCi0jICBkZWZpbmUg
    bnRvaF9zKG4pIG4NCi0jICBkZWZpbmUgbnRvaF9sKG4pIG4NCi0jICBkZWZp
    bmUgaHRvbl9zKG4pIG4NCi0jICBkZWZpbmUgaHRvbl9sKG4pIG4NCi0jZWxz
    ZQkvKiBCWVRFX09SREVSICE9IExJVFRMRV9FTkRJQU4gKi8NCi0jICBpZiBC
    WVRFX09SREVSID09IEJJR19FTkRJQU4NCi0jICAgIGRlZmluZSBudG9oX3Mo
    bikgKHVfc2hvcnQpKCgodV9jaGFyICopICZuKVswXSA8PCA4IHwgKCh1X2No
    YXIgKikgJm4pWzFdKQ0KLSMgICAgZGVmaW5lIG50b2hfbChuKSAodV9sb25n
    KSgoKHVfY2hhciAqKSZuKVswXSA8PCAyNCB8IFwNCi0JCQkJCQkJKCh1X2No
    YXIgKikmbilbMV0gPDwgMTYgfCBcDQotICAgICAgCSAgICAgICAgICAgICAJ
    ICAgKCh1X2NoYXIgKikmbilbMl0gPDwgOCB8ICgodV9jaGFyICopJm4pWzNd
    KQ0KLSMgICAgZGVmaW5lIGh0b25fcyhuKSAodV9zaG9ydCkoKCh1X2NoYXIg
    KikgJm4pWzJdIDw8IDggfCAoKHVfY2hhciAqKSAmbilbM10pDQotIyAgICBk
    ZWZpbmUgaHRvbl9sKG4pIChudG9oX2wobikpDQotIyAgZWxzZQkvKiBCWVRF
    X09SREVSICE9IEJJR19FTkRJQU4gKi8NCi0jICAgIGlmIEJZVEVfT1JERVIg
    PT0gUERQX0VORElBTg0KLSMgICAgICBlcnJvciBQRFBfRU5ESUFOIG1hY3Jv
    cyBub3Qgd3JpdHRlbiB5ZXQNCi0jICAgIGVsc2UJLyogQllURV9PUkRFUiAh
    PSAgYW55dGhpbmcga25vd24gKi8NCi0jICAgICAgZXJyb3IgQllURV9PUkRF
    UiBub3QgZGVmaW5lZCBhcyBhbnl0aGluZyB1bmRlcnN0b29kDQotIyAgICBl
    bmRpZgkvKiBCWVRFX09SREVSID09IFBEUF9FTkRJQU4gKi8NCi0jICBlbmRp
    ZgkvKiBCWVRFX09SREVSID09IEJJR19FTkRJQU4gKi8NCi0jZW5kaWYJCS8q
    IEJZVEVfT1JERVIgPT0gTElUVExFX0VORElBTiAqLw0KLQ0KKy8qIEFzIHdl
    IHVzZSB0aGUgc3lzdGVtIGh0b24qIGFuZCBudG9oKiBjYWxscyBpbiBoYmEu
    YywgcHFjb21tLmMsIA0KKyAgIHBxcGFja2V0LmMsIGZlLWF1dGguYywgZmUt
    Y29ubmVjdC5jIGFuZCBwb3N0bWFzdGVyLmMgd2Ugc2hvdWxkIHVzZSANCisg
    ICB0aGVzZSBjYWxscyBoZXJlIHRvby4NCisgICAJR2VyaGFyZCBSZWl0aG9m
    ZXINCisqLw0KIC8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
    LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLw0KIGlu
    dCBwcVB1dFNob3J0KGludCBpbnRlZ2VyLCBGSUxFICpmKQ0KICAgICB7DQog
    ICAgIGludCByZXR2YWwgPSAwOw0KICAgICB1X3Nob3J0IG47DQogCQkNCi0g
    ICAgbiA9IGh0b25fcyhpbnRlZ2VyKTsNCisgICAgbiA9IGh0b25zKGludGVn
    ZXIpOw0KICAgICBpZihmd3JpdGUoJm4sIHNpemVvZih1X3Nob3J0KSwgMSwg
    ZikgIT0gMSkNCiAgICAgCXJldHZhbCA9IEVPRjsNCiAgICAgDQpAQCAtNTgs
    NyArMjksNyBAQA0KICAgICBpbnQgcmV0dmFsID0gMDsNCiAgICAgdV9sb25n
    IG47DQogCQkNCi0gICAgbiA9IGh0b25fbChpbnRlZ2VyKTsNCisgICAgbiA9
    IGh0b25sKGludGVnZXIpOw0KICAgICBpZihmd3JpdGUoJm4sIHNpemVvZih1
    X2xvbmcpLCAxLCBmKSAhPSAxKQ0KICAgICAJcmV0dmFsID0gRU9GOw0KICAg
    ICANCkBAIC03NCw3ICs0NSw3IEBADQogICAgIGlmKGZyZWFkKCZuLCBzaXpl
    b2YodV9zaG9ydCksIDEsIGYpICE9IDEpDQogICAgIAlyZXR2YWwgPSBFT0Y7
    DQogCQkJDQotICAgICpyZXN1bHQgPSBudG9oX3Mobik7DQorICAgICpyZXN1
    bHQgPSBudG9ocyhuKTsNCiAgICAgcmV0dXJuIHJldHZhbDsNCiAgICAgfQ0K
    IA0KQEAgLTg3LDcgKzU4LDcgQEANCiAgICAgaWYoZnJlYWQoJm4sIHNpemVv
    Zih1X2xvbmcpLCAxLCBmKSAhPSAxKQ0KICAgICAJcmV0dmFsID0gRU9GOw0K
    IAkJCQ0KLSAgICAqcmVzdWx0ID0gbnRvaF9sKG4pOw0KKyAgICAqcmVzdWx0
    ID0gbnRvaGwobik7DQogICAgIHJldHVybiByZXR2YWw7DQogICAgIH0NCiAN
    Cg==
    - ---1463809280-1392365030-868541423=:7789--

    ------------------------------
  • Bruce Momjian at Jul 10, 1997 at 2:23 pm

    I'm a bit confused, what to test!

    1. We have a V6.1, which can talk only to same endian platform machines.
    Is that correct? True.
    2. V6.1p1 can talk to any V6.1p1 machine, but is strict using little
    endian byte order, which is reversed the the "standard network byte
    order". That's V6.1 with the patches "postgresql-v6.1-chngs-p1.tar".
    Is that correct?
    I am not sure what the current 6.1p1 has, but that is the goal, and what
    is in Thomas's new patch.
    3. V6.2 which should use "standard network byte order", which is intended
    to get implemented, but there's no code for that yet.
    Is that correct?
    We plan to switch "in a future release." Whether it is in 6.2 or not, I
    don't know.
    ======================================================================
    BTW in our office the attached V6.1 patch "pqcomprim.c.patch" has been
    applied. This leads to to the situation that Linux/AIX work in all
    combinations using the "standard network byte order".
    Yes, that will work too, but we really don't want to be making such a
    drastic change without warning everyone first.


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

    ------------------------------
  • Thomas G. Lockhart at Jul 10, 1997 at 2:52 pm

    Gerhard Reithofer wrote:
    OK, so to get the patch release rolling I would suggest the following
    changes:
    a) remove the endian #defines in postgres.h
    b) add a line #include <sys/machine.h> into aix.h,
    per Frank Dana's info
    c) add the endian #defines to the following <port>.h files,
    surrounded by #ifndefs:

    (grepping for BYTE_ORDER in include/port/*)
    dgux.h: #define BYTE_ORDER BIG_ENDIAN
    i386_solaris.h: #define BYTE_ORDER LITTLE_ENDIAN
    sparc_solaris.h:#define BYTE_ORDER BIG_ENDIAN
    sunos4.h: #define BYTE_ORDER BIG_ENDIAN
    ultrix4.h: #define BYTE_ORDER LITTLE_ENDIAN
    univel.h: #define BYTE_ORDER LITTLE_ENDIAN

    Are these changes sufficient to fix all current troubles with v6.1
    endian issues? We should have these specific changes tested by an AIX
    installation. Are there additional changes needed for HP/UX??
    1. We have a V6.1, which can talk only to same endian platform machines.
    Is that correct? Yes.
    2. V6.1p1 can talk to any V6.1p1 machine, but is strict using little
    endian byte order, which is reversed the the "standard network byte
    order". That's V6.1 with the patches "postgresql-v6.1-chngs-p1.tar".
    Is that correct?
    Yes, but with reported porting trouble to AIX and perhaps others.
    This version I've tested with patches:
    aix.h.patch
    postgres.h.patch
    applied, on the platforms Linux/Intel and AIX 4.1.
    For testing AIX 3.x we have to wait for Darren
    Both versions worked in all Server/Client combinations (Linix/Linux,
    AIX/AIX, AIX/Linux, Linux/AIX) - as I expected.
    Fantastic. I expect that, at worst, there are AIX3.2.5/AIX4.1
    differences which could be covered by an AIX-specific patch, with full
    Postgres port support in v6.2 (with your and Darren's contributions!).
    Hopefully we will hear soon from Tatsuo or someone else with a
    big-endian/little-endian mix on Solaris (machines which are missing all
    endian definitions).
    3. V6.2 which should use "standard network byte order", which is intended
    to get implemented, but there's no code for that yet.
    Is that correct?
    Mostly. Bruce has stated the opinion that a change in byte ordering
    should happen at a major release (v7.0) (btw, I vote with Bruce :).
    There may be one or several minor releases before then. Martin Laubach
    <mjl@emsi.priv.at> worked on this for v6.1 and would like to pursue it
    further with collaborators. Your patches below might form the basis for
    new work on this. There are some additional issues in the network
    protocol such as backend/frontend version identification which could be
    addressed.

    I might suggest putting in "network byte ordering" code with

    #ifdef USE_NETWORK_ORDER
    #else /* v6.0-compatible */
    #endif

    for v6.2 (which would by default have this undefined) and that would
    allow those of us who are interested to test the code for an extended
    period and would allow front-end developers to adapt their code to the
    new ordering well in advance of the major release.
    PS: Hope that I tested the correct combinations - Tom?
    If I understand correctly, yes! You took plain v6.1, added the v6.1p1
    patches, then added my e-mailed patches. I think your description above
    was clear. (No need to respond unless I got it wrong :)

    Thanks for staying with this until it is resolved!

    - Tom
    ======================================================================
    BTW in our office the attached V6.1 patch "pqcomprim.c.patch" has been
    applied. This leads to to the situation that Linux/AIX work in all
    combinations using the "standard network byte order".

    Best regards,
    Gerhard

    --- backend/libpq/pqcomprim.c.orig Wed Jun 11 06:00:32 1997
    +++ backend/libpq/pqcomprim.c Thu Jul 10 14:56:21 1997
    @@ -4,48 +4,19 @@
    #include "postgres.h"
    #include "libpq/pqcomm.h"

    -#ifdef HAVE_ENDIAN_H
    -# include <endian.h>
    -#endif
    -
    -
    /* --------------------------------------------------------------------- */
    -/* Is the other way around than system ntoh/hton, so we roll our own
    - here */
    -
    -#ifndef BYTE_ORDER
    -#error BYTE_ORDER must be defined as LITTLE_ENDIAN, BIG_ENDIAN or PDP_ENDIAN
    -#endif
    -
    -#if BYTE_ORDER == LITTLE_ENDIAN
    -# define ntoh_s(n) n
    -# define ntoh_l(n) n
    -# define hton_s(n) n
    -# define hton_l(n) n
    -#else /* BYTE_ORDER != LITTLE_ENDIAN */
    -# if BYTE_ORDER == BIG_ENDIAN
    -# define ntoh_s(n) (u_short)(((u_char *) &n)[0] << 8 | ((u_char *) &n)[1])
    -# define ntoh_l(n) (u_long)(((u_char *)&n)[0] << 24 | \
    - ((u_char *)&n)[1] << 16 | \
    - ((u_char *)&n)[2] << 8 | ((u_char *)&n)[3])
    -# define hton_s(n) (u_short)(((u_char *) &n)[2] << 8 | ((u_char *) &n)[3])
    -# define hton_l(n) (ntoh_l(n))
    -# else /* BYTE_ORDER != BIG_ENDIAN */
    -# if BYTE_ORDER == PDP_ENDIAN
    -# error PDP_ENDIAN macros not written yet
    -# else /* BYTE_ORDER != anything known */
    -# error BYTE_ORDER not defined as anything understood
    -# endif /* BYTE_ORDER == PDP_ENDIAN */
    -# endif /* BYTE_ORDER == BIG_ENDIAN */
    -#endif /* BYTE_ORDER == LITTLE_ENDIAN */
    -
    +/* As we use the system hton* and ntoh* calls in hba.c, pqcomm.c,
    + pqpacket.c, fe-auth.c, fe-connect.c and postmaster.c we should use
    + these calls here too.
    + Gerhard Reithofer
    +*/
    /* --------------------------------------------------------------------- */
    int pqPutShort(int integer, FILE *f)
    {
    int retval = 0;
    u_short n;

    - n = hton_s(integer);
    + n = htons(integer);
    if(fwrite(&n, sizeof(u_short), 1, f) != 1)
    retval = EOF;

    @@ -58,7 +29,7 @@
    int retval = 0;
    u_long n;

    - n = hton_l(integer);
    + n = htonl(integer);
    if(fwrite(&n, sizeof(u_long), 1, f) != 1)
    retval = EOF;

    @@ -74,7 +45,7 @@
    if(fread(&n, sizeof(u_short), 1, f) != 1)
    retval = EOF;

    - *result = ntoh_s(n);
    + *result = ntohs(n);
    return retval;
    }

    @@ -87,7 +58,7 @@
    if(fread(&n, sizeof(u_long), 1, f) != 1)
    retval = EOF;

    - *result = ntoh_l(n);
    + *result = ntohl(n);
    return retval;
    }
    ------------------------------
  • Tatsuo Ishii at Jul 11, 1997 at 3:44 am

    OK, so to get the patch release rolling I would suggest the following
    changes:
    a) remove the endian #defines in postgres.h
    b) add a line #include <sys/machine.h> into aix.h,
    per Frank Dana's info
    c) add the endian #defines to the following <port>.h files,
    surrounded by #ifndefs:

    (grepping for BYTE_ORDER in include/port/*)
    dgux.h: #define BYTE_ORDER BIG_ENDIAN
    i386_solaris.h: #define BYTE_ORDER LITTLE_ENDIAN
    sparc_solaris.h:#define BYTE_ORDER BIG_ENDIAN
    sunos4.h: #define BYTE_ORDER BIG_ENDIAN
    ultrix4.h: #define BYTE_ORDER LITTLE_ENDIAN
    univel.h: #define BYTE_ORDER LITTLE_ENDIAN

    Are these changes sufficient to fix all current troubles with v6.1
    endian issues? We should have these specific changes tested by an AIX
    installation. Are there additional changes needed for HP/UX??

    If these changes are agreeable, then I will commit changes to the source
    tree. It would help if those testing these changes would send any extra
    changes to ensure that nothing is left out. Tatsuo and Gerhard, could
    you try these on your mix of platforms?
    Sorry for the late reply. I was on a 2 days business trip.

    I tested your patches on the following mix of platforms.

    sparc_solaris: (your patch applied)
    suos4: (your patch and my sunos4.patch applied)
    MkLinux: (your patch and my MkLinux.patch applied)
    Linux/Intel: (plain 6.1p1)

    Any of these server/client combination worked fine!
    - --
    Tatsuo Ishii
    t-ishii@sra.co.jp

    ------------------------------
  • Thomas G. Lockhart at Jul 11, 1997 at 4:52 am

    If these changes are agreeable, then I will commit changes to the source
    tree. It would help if those testing these changes would send any extra
    changes to ensure that nothing is left out. Tatsuo and Gerhard, could
    you try these on your mix of platforms?
    Tatsuo Ishii wrote:
    I tested your patches on the following mix of platforms.
    sparc_solaris: (your patch applied)
    suos4: (your patch and my sunos4.patch applied)
    MkLinux: (your patch and my MkLinux.patch applied)
    Linux/Intel: (plain 6.1p1 (tgl- patches have no effect))
    Any of these server/client combination worked fine!
    Gerhard Reithofer wrote:
    (Tatsuo's and Tom's) versions worked in all Server/Client combinations
    (Linix/Linux, AIX/AIX, AIX/Linux, Linux/AIX) - as I expected.
    Thanks for verifying the patches!

    OK, are there any problematic platforms (other than Frank Ridderbusch's
    svr4.h variants which can be fully addressed for v6.2) still remaining?
    I think we have scattered reports of problems with some HP/UX releases,
    but I suspect that is similar to the AIX troubles where one release is
    OK and another has library or compatibility problems. Perhaps that also
    should wait for v6.2?

    Unless we hear that there is a supported platform which is still having
    trouble, tomorrow evening I will commit the patches I had e-mailed to
    the list. (OK Bruce, or am I rushing things too much :)

    Anything else need to be done for v6.1.1 (or whatever it's called)?

    - Tom

    ------------------------------
  • Bruce Momjian at Jul 11, 1997 at 5:19 am

    If these changes are agreeable, then I will commit changes to the source
    tree. It would help if those testing these changes would send any extra
    changes to ensure that nothing is left out. Tatsuo and Gerhard, could
    you try these on your mix of platforms?
    Tatsuo Ishii wrote:
    I tested your patches on the following mix of platforms.
    sparc_solaris: (your patch applied)
    suos4: (your patch and my sunos4.patch applied)
    MkLinux: (your patch and my MkLinux.patch applied)
    Linux/Intel: (plain 6.1p1 (tgl- patches have no effect))
    Any of these server/client combination worked fine!
    Gerhard Reithofer wrote:
    (Tatsuo's and Tom's) versions worked in all Server/Client combinations
    (Linix/Linux, AIX/AIX, AIX/Linux, Linux/AIX) - as I expected.
    Thanks for verifying the patches!

    OK, are there any problematic platforms (other than Frank Ridderbusch's
    svr4.h variants which can be fully addressed for v6.2) still remaining?
    I think we have scattered reports of problems with some HP/UX releases,
    but I suspect that is similar to the AIX troubles where one release is
    OK and another has library or compatibility problems. Perhaps that also
    should wait for v6.2?

    Unless we hear that there is a supported platform which is still having
    trouble, tomorrow evening I will commit the patches I had e-mailed to
    the list. (OK Bruce, or am I rushing things too much :)

    Anything else need to be done for v6.1.1 (or whatever it's called)?
    Let's get the patch installed as soon as possible. Then we can ask the
    general list for testers. I would like to announce something tomorrow
    so people can run tests over the weekend. Maybe Marc can generate a
    ftp site patch after you apply your patch.

    The HP-UX issue I remember is about random() and srandom() under HP-UX
    10.0. Earlier releases did not have these functions, so they are in the
    ports/hpux directory, but it seems new releases do. I was going to
    ask the person for a patch that would properly indenfify <10.0 vs 10.0,
    but decided we might as well just get this patch out and leave it for
    6.2.

    I believe we are calling this 6.1.1. I think it is too large to call it
    6.1p1. This is not a single-issue patch. I also think of patch-level
    releases as optional, and I don't believe this should be optional.
    Everyone should install it.



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

    ------------------------------
  • Bruce Momjian at Jul 11, 1997 at 5:24 am

    OK, are there any problematic platforms (other than Frank Ridderbusch's
    svr4.h variants which can be fully addressed for v6.2) still remaining?
    I think we have scattered reports of problems with some HP/UX releases,
    but I suspect that is similar to the AIX troubles where one release is
    OK and another has library or compatibility problems. Perhaps that also
    should wait for v6.2?

    Unless we hear that there is a supported platform which is still having
    trouble, tomorrow evening I will commit the patches I had e-mailed to
    the list. (OK Bruce, or am I rushing things too much :)
    I want to get this thing completed before Vadim returns from vacation. :-)



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

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 9, '97 at 9:08a
activeJul 11, '97 at 5:24a
posts12
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase