Skip to Content.
Sympa Menu

freetds - Re: [freetds] CS_INT size bug

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <james.k.lowden AT alliancebernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] CS_INT size bug
  • Date: Tue, 5 Sep 2006 18:09:16 -0400

> From: entropy AT freetds.org
> Sent: Tuesday, September 05, 2006 10:03 AM
>
> > entropy had written:
> >> CS_INT foo;
> >> ...
> >> printf("%ld\n", (long) foo);
>
> Norbert Sendetzky wrote:
> > I assume, you've used gcc which probably don't define long to 64
> > bit. Maybe it's only a problem when using the native plattform
> > compiler - but who does this today.
> >
> > On the other hand, did you get warnings in -Wall -pedantic mode?
>
> The code I suggested is *correct*. Instead of speculating endlessly
> why don't you just try it?

(Well. To try it would be to test the compiler. To know if it's
*correct* requires learning what's correct.) ;-)

Norbert, the point is that '%ld' says it's a *long* decimal and '(long)
foo' converts the argument 'foo' to a long. You tell printf to expect a
long, and you hand it a long. Whether a long is 32 or 132 bits doesn't
matter: long is long. The only assumption is pretty safe: that long is
defined the same way by the compiler compiling the application and the
compiler that compiled printf(3).

The good news is that Nick's cast works whether CS_INT is an alias for
int or long, because the one guarantee C makes about int and long is
that long is at least as big as int. That's why I said Nick's advice is
good form for an application writer.

The question I have is: Should we change our definition of CS_INT in
FreeTDS? In my copy of csconfig.h from Sybase 12.0 (for Win32) I have:

/*
** Certain Sybase C datatypes must be defined as 4 bytes in size. The
** following insures that all platforms (including 64 bit machines) use
** the correct C native types.
*/
#if defined( __alpha) || defined(SYB_LP64) || defined(_AIX)
typedef int CS_INT;
typedef int CS_RETCODE;
typedef int CS_BOOL;
typedef unsigned int CS_UINT;
#else
typedef long CS_INT;
typedef long CS_RETCODE;
typedef long CS_BOOL;
typedef unsigned long CS_UINT;
#endif

FreeTDS doesn't define or honor SYB_LP64, yet we define CS_INT as
tds_sysdep_int32_type i.e. 'int' on most (all?) 32-bit architectures.
That disagrees with Sybase's file. If we want application code to
compile cleanly irrespective of which library (Sybase's or FreeTDS) is
used, then we need to change our header file.

I don't know the history of SYB_LP64, so I don't know whether we should
support it. And I don't know if it's important to be compatible in this
way with Sybase's choices. But my instinct, a priori, is that we should
be compatible without replicating bugs.

OTOH, the Client Library Programmer's Guide says:

"Open Client/Server datatypes also permit application source
code to be
ported between platforms. For example, a CS_INT is always mapped to a
system
datatype that matches a four-byte integer."

"[M]apped to ... a four-byte integer." Strictly speaking, that's
exactly what we do with:

$ grep CS_INT include/* | grep typedef
include/cstypes.h:typedef tds_sysdep_int32_type CS_INT;

Nevertheless, there are undoubtedly many applications that assume CS_INT
is long, simply because Sybase says it is unless "defined( __alpha) ||
defined(SYB_LP64) || defined(_AIX)". And we could make the user's life
easier by following Sybase's lead. Or we could adhere to the letter of
the law and suggest users with such code either make it portable or
exercise their license to change the header file.

Bug or feature? What do ct-lib users think about this? It's your vote.
Use it.

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential and is intended only for the use of the person(s) named
above. If you are not the intended recipient, or an employee or agent
responsible
for delivering this message to the intended recipient, any review,
dissemination,
distribution or duplication of this communication is strictly prohibited. If
you are
not the intended recipient, please contact the sender immediately by reply
e-mail
and destroy all copies of the original message. Please note that we do not
accept
account orders and/or instructions by e-mail, and therefore will not be
responsible
for carrying out such orders and/or instructions. If you, as the intended
recipient
of this message, the purpose of which is to inform and update our clients,
prospects
and consultants of developments relating to our services and products, would
not
like to receive further e-mail correspondence from the sender, please "reply"
to the
sender indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New
York,
NY 10105.




Archive powered by MHonArc 2.6.24.

Top of Page