On Tuesday 25 of May 2010 11:33:39 Tor Arntsen wrote:
> Well, there's always the commit itself, which records all those changes.

Wait, that's not what I wanted to say. You can do s/bool/int/ now and you
can do the same fairly well two years later. However, if you do s/bool/int
now, you can't apply the reverted patch two years later. The information
is lost for ever.

> But I don't think a reverse is something we would want to happen. The
> problem with hiding basic C types via typedef, as done in this case,
> is that it doesn't buy us anything. Nothing. Not type safety for sure,
> because nothing in the C typedef mechanism prevents using a 'bool'
> type to receive an 'int' value (the case I fixed did just that, which
> caused the test 577 trouble).

If you want to do some observation, you may define 'bool' as 'int' in some
header. The result will be probably same. But please do not change
irreversibly all the code we have, just becase you don't consider it useful
at the moment.

> C just doesn't have a proper type safety system in place. Typedef

At which level do you mean? I am able to retrieve quite precise type
info from the gcc tree.

> doesn't do anything in that respect, it's not much better than a
> #define in this case. For this particular issue I'll argue that it

So what about the define? e.g. trigerred by some configure option?

> _decreases_ type safety, because it hides what goes on from the person
> reading the source. Consider:
>
> bool a = get_int_value();

You can still use the pseudo-operator '!!' to ensure you have bool value
in the variable, if the succeeding code relies on that.

> As a C programmer I immediately realises that 'bool' here is either a
> #define or a typedef. Without going hunting around I would guess it's
> typedef'ed to 'int', because that's the most common thing to see when
> people typedef 'bool' or 'boolean' or similar. So, hunting a problem,
> I'll decide it looks ok for now and continue reading the source
> because it doesn't look like it could cause the problem I'm seeing.
> But in this case it was actually typedef'ed to char. That was what
> caused the 577 trouble. Problem is, nothing prevents you doing that in
> C, and a typedef can only hide the problem even more. If you instead
> see

You're considering only your current compilator working in the way you use
it. Beyond that we have other equipment for anylyzing type-safety - advanced
compilers, compiler plug-ins, tools for static analysis, hopefully soon also
some usable tools performing formal verification and so on and so forth.

> char a = get_int_value()
>
> it's clear right away that it could be fishy.
>
> IMO it's OK to use typedef in certain cases. But not for basic C
> types. Over the years of code maintenance I've been doing at work I've
> concluded that if you use basic C types it does _not_ help to typedef
> them to something else, with maybe the idea that the basic type could
> be changed to something different later, and there would be only one
> place to modify then. But it doesn't work that way in practice. Not in
> C. It's much better to think carefully about which basic type you
> really need, and then use it, as is. What we've done with the code
> base at work includes removing typedefs when used for basic C types,
> and often elsewhere too. This has definitely improved the code quality
> for us.
>
> Lots of other people have come to the same conclusion. This page sums
> it up nicely I think:
> http://www.45mercystreet.com/computing/typedefs.html

The fact that some extra information is not useful is not enough reason
for its immediate removal from my perspective. If the reason is to show
up some bugs hidden till now, there are surely other (non intrusive) ways
to do it. I am open to discuss them.

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