FreeTDS Development Group

[Sebastien FLAESCH <sf AT 4js.com>]

Oups actually, it's the UnixODBC definition of the SQLParamOptions() function 
which is wrong...

This is what you (Steve) explain in previous mails (go fix UnixODBC)... right?

Sorry for the spam ;-)
Seb

Sebastien FLAESCH wrote:
> Thank you Steve,
>
> Here is what we have tested:
>
> CFLAGS="-D BUILD_REAL_64_BIT_MODE" ./configure --prefix=/opt3/dbs/tds/0.83 
> --with-odbc-nodm=/opt3/dbs/uxo/3.0
>
> But when compiling, we get:
>
> odbc.c:794: conflicting types for `SQLParamOptions'
> /dbs/64bits/uxo/3.0/include/sqlext.h:1893: previous declaration of 
> `SQLParamOptions'
>
> Am I missing something or is this what Christos tried to fix?
>
> The headers comme from UnixODBC 2.2.12 ...
>
> Cheers,
> Seb
>
> Steve Langasek wrote:
> > Hi Sebastien,
> >
> > On Fri, Jan 18, 2008 at 09:19:18AM +0100, Sebastien FLAESCH wrote:
> > > So first I doubt that Christos patch is I good idea:
> > > -SQLParamOptions(SQLHSTMT hstmt, SQLULEN crow, SQLULEN FAR * pirow)
> > > +SQLParamOptions(SQLHSTMT hstmt, SQLUINTEGER crow, SQLUINTEGER FAR * pirow)
> > > Changing SQLULEN to SQLUINTEGER in FreeTDS would break the standards... no?
> > Yes, I didn't look closely at this part of the patch.  In those cases where
> > the ODBC standard is historically broken for 64-bit, it's because the API
> > calls for a SQLUINTEGER or SQLINTEGER where a 64-bit SQLLEN/SQLULEN is
> > needed to accomodate the range of possible values being passed; it would
> > never be appropriate to change an API call that's specified as SQLULEN to
> > SQLUINTEGER instead as part of the 64-bit porting.
> >
> > > If we don't define BUILD_REAL_64_BIT_MODE, SQLLEN would be an int4, since
> > > int is 4 bytes on a 64b linux ... right?
> > All 64-bit Linux implementations are LP64, which means sizeof(int) = 4, yes.
> >
> > Cheers,
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds