Skip to Content.
Sympa Menu

freetds - Re: [freetds] tds_money_to_string conversion oddity

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] tds_money_to_string conversion oddity
  • Date: Tue, 9 Dec 2003 01:43:40 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page