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: entropy AT freetds.org
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] CS_INT size bug
  • Date: Wed, 06 Sep 2006 00:59:00 -0400

Lowden, James K wrote:

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.

I think we already are compatible in the way that matters: our CS_INT is 4 bytes long. The whole point of that conditional code in the Sybase header is to ensure that CS_INT is a 32-bit integer type (read the comment!) Whether that type happens to be called "int" or "long" really isn't terribly important.

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.

Any user code that assumes CS_INT is long is broken, because we know there are cases where CS_INT *is not* long. Application code, to be strictly correct in both LP32 and LP64 environments must be able to cope with those cases. I've already provided code that shows how easy that is to do, so I think it's pointless to change.

I have no strong objection to trying to use "long" in preference to "int" when both are 32-bit types, but I do think it's a waste of time. We're long past the days when "all the world's a VAX", and it's time for application coders to start learning how to use the C language properly. A few extra warnings to nudge them in the right direction isn't a bad thing.

IMNSHO, of course.

--
Cheers,
entropy




Archive powered by MHonArc 2.6.24.

Top of Page