On Sun, Dec 16, 2012 Daniel Stenberg wrote:
>
> On Sun, 16 Dec 2012, Yang Tse wrote:
>
>> The purpose of internally using the bool data type was to detect and avoid
>> unclever assignments to bool variables, attempting to get compiler warnings
>> or errors when such a condition existed.
>
>
> While a good intention, I think it is time to reevaluate if this is really
> doable nicely in the long run.

It should be. Although there might exist few compilers/headers for
which a subtle adjustment of detection or definition logic is
required. A specific case of these is the HP-UX one. But read
further...

>> Modify libcurl to use 'private' namespace. Use 'curl_bool' instead of
>> 'bool', CURL_TRUE instead of TRUE, CURL_FALSE instead of FALSE.
>>
>> 'curl_bool' could be our own enum definition only for systems which lack
>> 'bool' or for all.
>
>
> I like using the traditional 'bool' name for the simple reason that it is
> familiar and what people will use and understand. Also because it prevents
> someone one from _wrongly_ introducing bool in a patch down the road when we
> miss that the contributor doesn't use curl_bool...

Yes, I also dislike the 'curl_bool' renaming.

> I think we can go back to have TRUE and FALSE just be 1 and 0 for systems
> without a bool of their own.

I prefer we keep current usage and definitions, which allows detection
of bad bool assignments on systems such as IRIX. And more now that the
HP-UX issue can be properly fixed without the need of 'curl_bool'.

I'm pushing now a quite short and proper fix for the HP-UX issue, that
also reverts problematic commit f254c59dc7. See
https://github.com/bagder/curl/commit/b8dde1cf

@Frank Chang

Verify if this b8dde1cf commit fixes the issue for you.

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html