Skip to Content.
Sympa Menu

freetds - Re: [freetds] FreeTDS Digest, Vol 44, Issue 4

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: entropy AT freetds.org
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] FreeTDS Digest, Vol 44, Issue 4
  • Date: Mon, 04 Sep 2006 16:16:46 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page