[freetds] CS_INT size bug

Norbert Sendetzky norbert at linuxnetworks.de
Thu Sep 7 12:20:01 EDT 2006


On Thursday 07 September 2006 18:00, freetds-request at lists.ibiblio.org wrote:
> > 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.
>
> First of all, CS_INT is always 32 bits.  It doesn't matter if it is
> called int or long, it is still 32 bits.  It's defined that way by
> Sybase, and it's defined that way by FreeTDS.  You can rest assured that
> CS_INT will always be 32 bits.

Then

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

should be fine now.

> Second of all, your code is wrong, but not for the reason you think.
> You can't cast a (CS_CHAR *) to a (CS_INT *) and safely use the result
> to access integral types.  There is no guarantee that a CS_CHAR * will
> be aligned on a boundary safe for 32-bit integer access.

I know that. val[i].value is a malloc()'ed array and therefore save because 
it's properly aligned.

Thanks


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc

-------------- 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/20060907/8b5ae477/attachment.bin 


More information about the FreeTDS mailing list