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