[freetds] FreeTDS Digest, Vol 44, Issue 4
entropy at freetds.org
entropy at freetds.org
Mon Sep 4 16:16:46 EDT 2006
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
More information about the FreeTDS
mailing list