cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: s/bool/int

From: Tor Arntsen <tor_at_spacetec.no>
Date: Wed, 26 May 2010 11:03:57 +0200

On Wed, May 26, 2010 at 10:33, Michael Schuster
<michael.schuster_at_oracle.com> wrote:
> On 26.05.10 10:04, Tor Arntsen wrote:
>
>> Ok, I'll try from another direction then.. can anyone point to any
>> real-life scenarios where using things like
>>
>> typedef unsigned char bool
>
> no, I cannot (readily, anyway).
>
> I feel this discussion - while you certainly make a point - is putting
> emphasis on one aspect only.
> What concerns me more is the fact that booleans and integers are
> semantically completely different, and the suggested change would completely
> lose all information about this difference.

Oh, I absolutely agree with that. That's not the problem. The problem
is that as long as we're dealing with C it is, to say it bluntly,
wishful thinking to believe that to change names of basic types by
using typedefs will improve things. As long as the language support
isn't behind it it won't. I used to do the 'typedef .. bool' thing
myself, a long time back. I have only come to regret it.

For the particular issue of ints that are sometimes numbers and
sometimes only 0 and non-0, (aka FALSE and TRUE), C programmers have
long since learned to deal with that. They're pretty good at it, for
the most part. What throws a wrench into the system is when there's a
typedef there - that's when mistakes are made (depending on what the
typedef, hidden away in some header file, actually did).

> If C (and the current compilers) does not offer the inherent type safety
> you're looking for, maybe this calls for some extra programming discipline
> to make it as hard as possible to confuse integers and booleans (btw: I've
> never seen a char type used as boolean, only integer) - I guess there's
> several ways, stringent naming conventions come to mind as one: eg "is_bla"
> for a boolean, "item_count" for a counter, etc. Variable names like "a" are
> mostly meaningless outside very tight scope.
> Avoiding implicit comparisons like
>        if (ptr)
> for anything non-booelean, and using
>        if (ptr != NULL)
> is another step in the right direction (and no, that's not my invention, and
> yes, I'll readily agree that long exposure to Solaris source has it's
> effects ;-)

Well, I can only say that for my own coding I at least follow some of
your suggestions already :-). Certainly the if() stuff. Naming
conventions don't tend to work out too well, at least not the very
rigid ones - I'm sure some people here remember the horrors of
Hungarian notation. But some variable-name dicipline is good, of
course. For that particular case which I fixed the name was good
though.. 'found' sounds nice&boolean.

Maybe the bool/int/typedef issue is the worst one though (as in:
Easiest to mess up). For that particular case, if you really want to
keep a bool type, why not make it an 'enum' instead? Because some
compilers will yell at you if you try to assign any random int to an
enum. The enum handling is being handled slightly stronger by some
current-generation compilers (unlike in the past where it was exactly
as just a define). Just a thought.

-Tor
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-05-26