cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl_off_t suffix

From: Jamie Lokier <jamie_at_shareable.org>
Date: Fri, 15 Aug 2008 18:44:58 +0100

Dan Fandrich wrote:
> On Thu, Aug 14, 2008 at 10:25:55AM +0100, Jamie Lokier wrote:
> > Dan Fandrich wrote:
> > > #define INT64_C(x) (x + (INT64_MAX - INT64_MAX))
> >
> > I wonder why they did that??!
> >
> > If x is a large constant, how is that (123456789012345 + (INT64_MAX -
> > INT64_MAX)) is acceptable to the compiler (note no suffix on the
> > constant), but simply the constant by itself, or ((__int64_t)
> > 123456789012345), are not?
>
> I'm guessing the tokenizer treats the value as 64 bit internally, then
> truncates it to a normal 32 bit int before using it in many contexts
> (as per the C standard). Adding a long long to the value forces it to
> remain as 64 bits.

You're saying the compiler truncates a constant in this expression:

    (__int64_t) 123456789012345

But _doesn't_ truncate it in this expression:

    (123456789012345 + (9223372036854775807LL - 9223372036854775807LL))

That's pretty bizarre, truncating prior to cast, but not truncating
prior to addition. Are you sure any compiler does that? Both
addition and casts seem to have an equal footing in C's "arithmatic
constant expressions". (Btw, C99 doesn't require the LL suffix to
produce correct code, although I realise most of the compilers aren't C99).

  -- Jamie
Received on 2008-08-15