FreeTDS Development Group

[entropy AT freetds.org]

Christos Zoulas wrote:
> On Sep 4,  2:15pm, entropy AT freetds.org (entropy AT freetds.org) wrote:
> -- Subject: Re: [freetds] FreeTDS Digest, Vol 44, Issue 4
>
> | Irrelevant to what we were discussing: use of the FreeTDS-defined CS_INT 
> | from user application code.  CS_INT is part of CS-Library/CT-Library, 
> | not ODBC.
>
> CS_INT should be int32_t, since it needs to be a 4 byte signed integer.
> This is the problem. 

That's not a problem, because CS_INT is defined that way.

> CS_INT is abused by the ODBC API (is that a formal
> API?) to pass pointers around, and this of course does not work. 

Then I must be in the twilight zone, because I can't find any reference 
to CS_INT anywhere in our ODBC code.

> Defining
> CS_INT to long on LP32 machines is not very useful, but at least works
> (modulo printf format breakage, that can be handled with casts).
> Defining CS_INT to be long on 64 bit machines, plainly does not work.

The definition of CS_INT is fine as it is, and changing it should have 
exactly zero effect on anything having to do with ODBC.

> | > Don't you get warnings when compiling?
> | 
> | If you mean when compiling the FreeTDS OBDC library, yes, I do.  I don't 
> | know enough about ODBC to fix it.  Do you have a patch to offer?
>
> I can silense the compiler, but I cannot provide a patch that works, since
> it is impossible to fit 8 byte arbitrary pointers into 4 bytes. What needs
> to be done, is to introduce CS_POINTER and use it where pointers are needed.
> This is an API change.

Well, CS_POINTER certainly has no place in ODBC because CS_anything is 
part of the CS-Library API and not ODBC.  I can't fathom where you're 
coming from, except to assume that you don't understand that FreeTDS 
provides three completely independent API's.  Pointing to the 
CS/CT-Library API as a source of breakage in the ODBC API is just plain 
wrong.

I would guess that ODBC needs to use some pointer type (SQLPOINTER???) 
instead of trying to do inherently broken things like stuffing a pointer 
into an integral type.  But again, I'm not the person to say how this 
should be corrected in our implementation.  I'll leave this to our ODBC 
guru (Freddy) and bow out of the thread at this point.

--
Cheers,
entropy