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: Norbert Sendetzky <norbert AT linuxnetworks.de>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] CS_INT size bug
  • Date: Thu, 7 Sep 2006 18:20:01 +0200

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

Attachment: pgpqcor0mc_w1.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page