FreeTDS Development Group

[christos AT zoulas.com (Christos Zoulas)]

On Sep 4,  4:16pm, entropy AT freetds.org (entropy AT freetds.org) wrote:
-- Subject: Re: [freetds] FreeTDS Digest, Vol 44, Issue 4

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

You need to look at the headers where SQLINTEGER is used to create other
types used to pass pointers.

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

Which is what I said. I did not say that it should be changed to long. I said
it needs to be 4 bytes. The same with SQLINTEGER.

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

Yes, I got confused; I meant SQLPOINTER not CS_POINTER.

christos