Обсуждение: long ints use for 4-byte entities in ODBC

Hi,

I was installing the ODBC driver on an alpha box.  Problem is that there 
are assumptions in the typedefs that a four byte integer is a "long 
int".  Of course, this is often an incorrect assumption.  I can fix this, 
but wanted to know how people wanted this done.  How do you handle this 
issue in the server?  Seems confingure.in and associated files is the most 
reasonable way to fix this to me.

Cheers,


-- Andrew Bell
acbell@iastate.edu       

> I was installing the ODBC driver on an alpha box.  Problem is that there
> are assumptions in the typedefs that a four byte integer is a "long
> int".  Of course, this is often an incorrect assumption.  I can fix this,
> but wanted to know how people wanted this done.  How do you handle this
> issue in the server?  Seems confingure.in and associated files is the most
> reasonable way to fix this to me.

Also; which driver manager are you using? I think Nick Gorham has been 
working on this issue within unixODBC.

Peter

At 11:41 AM 12/20/2001 +0000, Nick Gorham wrote:
>Peter Harvey wrote:
>
> > > I was installing the ODBC driver on an alpha box.  Problem is that there
> > > are assumptions in the typedefs that a four byte integer is a "long
> > > int".  Of course, this is often an incorrect assumption.  I can fix this,
> > > but wanted to know how people wanted this done.  How do you handle this
> > > issue in the server?  Seems confingure.in and associated files is the 
> most
> > > reasonable way to fix this to me.
> >
> > Also; which driver manager are you using? I think Nick Gorham has been
> > working on this issue within unixODBC.
> >
> > Peter
>
>AFAIK there should be nothing wrong with
>
>typedef Int4 int
>
>instead of the
>
>typedef Int4 long
>
>which is plainly wrong on 64 bit platforms.

Of course, the C standard doesn't say anything about the sizes of any of 
the int-like datatypes, it only specifies their relative sizes.  MySQL 
(don't throw stones) addresses the problem like this in configure.in:

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

AC_CHECK_SIZEOF(int, 4)
if test "$ac_cv_sizeof_int" -eq 0
then  AC_MSG_ERROR("No size for int type.")
fi
AC_CHECK_SIZEOF(long, 4)
if test "$ac_cv_sizeof_long" -eq 0
then  AC_MSG_ERROR("No size for long type.")
fi
AC_CHECK_SIZEOF(long long, 8)
if test "$ac_cv_sizeof_long_long" -eq 0
then  AC_MSG_ERROR("MySQL needs a long long type.")
fi
# off_t is not a builtin type
MYSQL_CHECK_SIZEOF(off_t, 4)
if test "$ac_cv_sizeof_off_t" -eq 0
then  AC_MSG_ERROR("MySQL needs a off_t type.")
fi

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

Coupled with a few SIZEOF_<datatype> checks in the headers which set up the 
typedefs for sized data, the problem is solved generically.


-- Andrew Bell
acbell@iastate.edu       

Peter Harvey wrote:

> > I was installing the ODBC driver on an alpha box.  Problem is that there
> > are assumptions in the typedefs that a four byte integer is a "long
> > int".  Of course, this is often an incorrect assumption.  I can fix this,
> > but wanted to know how people wanted this done.  How do you handle this
> > issue in the server?  Seems confingure.in and associated files is the most
> > reasonable way to fix this to me.
>
> Also; which driver manager are you using? I think Nick Gorham has been
> working on this issue within unixODBC.
>
> Peter

AFAIK there should be nothing wrong with

typedef Int4 int

instead of the

typedef Int4 long

which is plainly wrong on 64 bit platforms.

--
Nick Gorham
Easysoft Ltd