[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