2008/6/12, Dan Fandrich wrote:

> > Given a compiler/system that has an intrinsec 64-bit "long long" data
> > type and an "int64_t" declared in <stdint.h>" which one should we
> > prefer for curl_off_t ?
> >
> > It seems to me that it would be reasonable to prefer the compiler
> > intrinsec data type over the library one. But I'm asking for other
> > opinions.
>
> It seems safest to use int64_t if it's available. That will also work on
> oddball compilers that we don't take care of separately.

Both int64_t and PRId64 have to be available when stdint.h and
inttypes.h are included, if not I will asume that something is wrong
and won't use int64_t when PRId64 is missing, for configure capable
systems.

Typedef'ing int64_t to curl_off_t in the public libcurl headers has
the side effect that stdint.h and inttypes.h must be #included in the
libcurl public headers quite early so that the typedef can actually
take place and also define CURL_FORMAT_OFF_T headers from the
definition of PRId64.

This also implies that libcurl headers would have a dependancy on
stdint.h and inttypes.h.

The above happens equally for any type of build system used, it only
depends on the use of int64_t for curl_off_t or not.

Once that I've said that...

I don't really care if we give preference to int64_t or to the other
64-bit data types. I'm coding both checks for the configure script.
But wanted to remember the above header stuff.

And no matter which one we give preference, there will most probably
be a system in which stdint.h and inttypes.h is pulled into libcurls
public headers.

So it is only a matter of choosing what we want to happen more commonly.

Further thoughts ?

-- 
-=[Yang]=-