FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

On 08 Dec 2003, Frediano Ziglio <freddyz77 AT tin.it> wrote:
> Il lun, 2003-12-08 alle 19:47, Craig Berry ha scritto:
> > >> 
> > >> #if SIZEOF_LONG < 8
> > >> 
> > >> which means that sizeof(long int) < 8, but I think what you really
> > >> want is sizeof(long long int) or perhaps sizeof(__int64)  since a
> > >> long int is sometimes (usually?) still 32 bits even on 64-bit
> > >> platforms.  
> 
> I'm getting a bit confused... FreeTDS detect the 64 bit type
> (TDS_INT8/TDS_UINT8) however the problem is printf formatting. We do not
> define a 64 bit formatting... With #if SIZEOF_LONG < 8 line I detect if
> %ld accept a 64 bit int (or in other words if long is 64 bit). %lld
> isn't so portable and so I used %ld. Perhaps a test for printf
> formatting and some define can help... For example gcc accept long long
> however system library supports %lld?? Windows accepts %i64. I think
> some platforms do not accept 64 bit int... So there is not a portable 
> way to transform a 64 bit int to a string...

I don't think you're confused.  In fact, you clarified the point.  

The question: given a 64-bit integer, how to convert it to a string?  

        sprintf( "%d", i );
        sprintf( "%ld", i );
        sprintf( "%lld", i );
        sprintf( "%i64", i );

Perhaps we should do something like what we did with milliseconds and
strftime(3): invent our own true "long integer" escape for "tds_sprintf"
(I think '%L' is available), and use autoconf macros to substitute the
right formating string, then have tds_sprintf call sprintf(3) as
appropriate.  

> Here we use a sprintf that can cause lose of precision. 

See, I don't understand "lose precision".  money->string calls for two
decimal places of precision.  We're supposed to lose precision; darkness
is the standard.  What's the problem?  

I agree with your point that the sprintf I added was a hack.  First we
scale it up, then I round it off with sprintf; more efficient to stop at
two decimals.  But it was cheap and fast; good costs extra.  

> However
> such systems have others problem in convert.c... Should we fix these
> problems too or should we require 64 bit support ?? 

I'm OK with requiring 64-bit support, so long as failures are clear and
loud.  (Do I hear <assert.h>?)  It might be easier to fix the problems?  

--jkl