cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: yangtse: curl CHANGES,1.1433,1.1434 acinclude.m4,1.198,1.199

From: Yang Tse <yangsita_at_gmail.com>
Date: Fri, 15 Aug 2008 19:05:54 +0200

2008/8/15, Daniel Stenberg wrote:

> On Fri, 15 Aug 2008, cvs_at_labb.contactor.se wrote:
>
> > Remove the use of an internal name for the curl_off_t formatting string
> directives and use the common one available from the inside and outside of
> the library.
> >
> > FORMAT_OFF_T -> CURL_FORMAT_CURL_OFF_T
> > FORMAT_OFF_TU -> CURL_FORMAT_CURL_OFF_TU
> >
>
> Yang,
>
> Do consider that internally we use our own printf() code everywhere and this
> code accepts a different format that the "regular" one for the system the
> libcurl code compiles on. That was the original reason for the two different
> defines and while it may turn some things a little messier (having two
> defines with the same purpose only differening for what function they're
> used for), it keeps the internal printf() code simpler...

Yes, the moment of speaking about mprintf.c source code seems to have
arrived. I have been postponing until I would have looked deeper into
it. But now that you mention it, this brings the issue into scope, and
your help is surely needed.

Lets see if I'm capable of properly writing my thoughts...

There are several facts that intermix here.

First, the one you mention.

Up to, and included, libcurl version 7.18.2 internal print formatting
strings were defined in setup.h as:

#if SIZEOF_CURL_OFF_T > 4
# define FORMAT_OFF_T "lld"
#else
# define FORMAT_OFF_T "ld"
#endif

The initial 64-bit curl_off_t patch changed this in revision 1.147 of
setup.h to:

#ifdef FORMAT_OFF_T
# error "FORMAT_OFF_T shall not be defined before this point!"
#else
# define FORMAT_OFF_T CURL_FMT_OFF_T
#endif

Effectively, mapping the external definition to the internal one,
making them the same. This might have gone unnoticed until earlier
connit done today, but there has certainly been no intention of hiding
it at any moment.

The problem of doing this is that our printf clones in mprintf.c do
nor understand formatting string directives 'i64', 'i32', 'i16', 'i8',
and their respective 'i64u', 'i32u', 'i16u', 'i8U', neither the
uppercase literals which are also admitted on some compilers/systems
printf..

Here we can bite the bullet and make our printf clone understand those
print formatting directives, which have the benefit of exposing the
size of the integer var intended to be printed.

Another option is to undo the mapping of the internal print directives
to the external ones (partial reversion of last commit done) leaving
it as it was in the 7.18.2 version.

There's a second multiple issue, related but independant of the
previous one, which exists anyway no matter which route we go with the
first one.

The width of a 'long' might be 32 or 64 bits.
The width of a 'long long' might be 64 or more bits.
The width of a 'curl_off_t' might be 64 or less bits.
I don't fully understand the logic in mprintf related with ENABLE_64BIT.

Ok, probably I'm confusing myself with the code in mprintf.c and the 4
above statements. So here is where I really ask you to take a look at
it and see what should be done.

If you want me to undo the mapping of the internal print directives to
the external ones, just tell me and I'll undo it. But please take a
look at mprintf.c

-- 
-=[Yang]=-
Received on 2008-08-15