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: christos AT zoulas.com (Christos Zoulas)
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] FreeTDS Digest, Vol 44, Issue 4
  • Date: Mon, 4 Sep 2006 17:05:04 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page