SOURCES: unixODBC-types.patch - do it the riht way using SIZEOF_LONG

[Jakub Bogusz]

On Fri, Oct 08, 2004 at 07:40:11PM +0200, havner wrote:
> On Fri, Oct 08, 2004 at 10:54:46AM +0200, Jakub Bogusz wrote:
> > On Sun, Oct 03, 2004 at 01:39:00AM +0000, havner wrote:
> > > Author: havner                       Date: Sun Oct  3 01:39:00 2004 GMT
> > > Module: SOURCES                       Tag: HEAD
> > > ---- Log message:
> > > - do it the riht way using SIZEOF_LONG
> > > 
> > > ---- Files affected:
> > > SOURCES:
> > >    unixODBC-types.patch (1.1 -> 1.2) 
> > > 
> > > ---- Diffs:
> > > 
> > > ================================================================
> > > Index: SOURCES/unixODBC-types.patch
> > > diff -u SOURCES/unixODBC-types.patch:1.1 SOURCES/unixODBC-types.patch:1.2
> > > --- SOURCES/unixODBC-types.patch:1.1	Sat Oct  2 23:14:42 2004
> > > +++ SOURCES/unixODBC-types.patch	Sun Oct  3 01:38:54 2004
> > > @@ -1,15 +1,19 @@
> > >  diff -ur unixODBC-2.2.9.orig/include/sqltypes.h unixODBC-2.2.9/include/sqltypes.h
> > >  --- unixODBC-2.2.9.orig/include/sqltypes.h	2004-06-25 19:01:15.000000000 +0200
> > > -+++ unixODBC-2.2.9/include/sqltypes.h	2004-10-03 00:51:29.842492392 +0200
> > > -@@ -256,9 +256,9 @@
> > > ++++ unixODBC-2.2.9/include/sqltypes.h	2004-10-03 03:35:55.969613088 +0200
> > > +@@ -256,9 +256,14 @@
> > >   typedef signed short int        SWORD;
> > >   typedef unsigned short int      UWORD;
> > >   typedef unsigned int            UINT;
> > > --typedef signed long             SLONG;
> > > ++#if (SIZEOF_LONG == 4)
> > > + typedef signed long             SLONG;
> > > +-typedef signed short            SSHORT;
> > > + typedef unsigned long           ULONG;
> > > ++#else
> > >  +typedef signed int              SLONG;
> > > - typedef signed short            SSHORT;
> > > --typedef unsigned long           ULONG;
> > >  +typedef unsigned int            ULONG;
> > > ++#endif
> > > ++typedef signed short            SSHORT;
> > >   typedef unsigned short          USHORT;
> > >   typedef double                  SDOUBLE;
> > >   typedef double            		LDOUBLE;
> > 
> > Skąd informacja, że SLONG/ULONG w API/ABI ODBC mają być 32-bitowe?
> > Jest to w jakiejś specyfikacji ODBC?
> > 
> > Druga rzecz, to taka zmiana wymaga zmiany SONAME na 64-bitowych
> > architekturach ze względu na binarną niekompatybilność.
> 
> Tak wymaga tego Firebird. W naglowku jest wyraznie napisane, ze
> wymuszaja 32bit na 64bit architekturach. I przy takim ODBC nie budowal
> sie php (includowal oba, i byl konfikt typow) Spytalem arekm co z tym
> zrobic. Powiedzial, ze chyba najlepiej wymusic to w ODBC, zeby bylo
> calkowicie jednolite. Nie mam pewnosci jak powinno byc, ale nikt inny
> nie chcial tego poprawic.

Firebird nie jest tu żadnym wyznacznikiem, bo nie dostarcza API ODBC(?),
więc jest to tylko konflikt nazw typów używanych do różnych rzeczy - do
rozwiązania w inny sposób (pewnie jakimiś hackami z #define).
mikmod też używa 32-bitowych typów o nazwach [SU]LONG, a ma jeszcze
mniej wspólnego z ODBC.

Jak to w unixODBC (i libiodbc) powinno być, to zależy do czego służy,
czy jest używane lokalnie czy zdalnie itd. - trzeba by pośledzić.
Czy to mają być typy odpowiadające danym typom C, czy zawsze o tym samym
rozmiarze (ale od tego jest UDWORD i SDWORD).

Nie wiem czy jest do tego jakaś specyfikacja uwzględniająca konwencję
LP64 - bo z tego co słyszałem Win64 używa LLP64, więc ma 32-bitowego
longa.

Tutaj znalazłem jakieś uwagi dot. 64-bitowego ODBC - jest parę zmian,
ale SLONG i ULONG jest zawsze longiem.

http://www-numi.fnal.gov/offline_software/external_pkgs/Linux2.4-GCC_3_2/include/sqltypes.h

Zmieniając tak sobie sqltypes.h dostajemy binarną niekompatybilność
w ramach bibliotek ODBC z innymi dystrybucjami na 64-bitowego Linuksa
oraz ze wszystkimi naszymi binarkami budowanym na ODBC przed tą zmianą.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/