FreeTDS Development Group

[entropy AT freetds.org]

Norbert Sendetzky wrote:

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

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.

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.

If you're unlucky, and the alignment is off, and you're on a picky 
architecture, your code will dump core when it tries to access the first 
value.  If you're *really* unlucky, it will work fine on your test 
platform, and dump core randomly when you put it into production.

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

Your knowledge is faulty.  A long is always *at least* 32 bits.  A short 
is the same or smaller than an int, and an int is the same or smaller 
than a long.  If your code makes any other assumptions about sizes of 
these data types, your code is not portable.  Please refer to section 
2.2 of _The C Programming Language_ 2nd ed.  (Kernighan & Ritchie)

--
Cheers,
entropy