[freetds] CS_INT size bug

Norbert Sendetzky norbert at linuxnetworks.de
Wed Sep 6 13:53:26 EDT 2006

Hi James

> > 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).

You are right and entropy's code produces always the correct results.
The reason why I'm hesitating is that ctlib binds results to an array and my 
code looks like this:

length = snprintf( value, collength, "%ld", *((CS_INT*) val[i].value) );

where val[i].value is a CS_CHAR array. In this case I still think it does make 
a difference if CS_INT is 32 or 64 bit because using the first eight bytes 
instead of the only the first four results in garbage.

> 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.

This assumption conflicts with my current knowledge that INT is autosizing and 
uses the native machine register size whereas LONG is always 32 bit (with the 
great exception of Alpha and AIX if I unterstood the Sybase header 
correctly). Maybe you can prove me wrong ...

> 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:
> Bug or feature?  What do ct-lib users think about this?  It's your vote.
> Use it.

Well, it seems to me that Sybase's definition of CS_INT isn't a bug and 
FreeTDS is promoted as a drop-in replacement for ctlib, so ...

Thanks for your time and help

OpenPGP public key

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20060906/63270ab6/attachment.bin 

More information about the FreeTDS mailing list