On Wed May 26 2010 10:04:23 Tor Arntsen wrote:
> On Tue, May 25, 2010 at 21:24, Kamil Dudka <kdudka_at_redhat.com> wrote:
> Maybe the gcc tree knows about it, but this doesn't mean much for the
> language itself. C is not a strongly typed language, not when you
> compare to e.g. Pascal and the like. It doesn't prevent you from
> doing:
> unsigned char a = get_int_value();

If you want gcc to prevent you from doing the above, you can load
a plug-in doing exactly that.

> With a strongly typed language you should be able to do:
>
> typedef unsigned char bool;
> bool a = get_int_value() <- returns int
> and it would refuse to compile.
> Even
> bool a = get_unsigned_char_value()
> should fail. It doesn't.
> So. what the typedef does is only to hide the problem from being easy
> to spot. If it could prevent coders from assigning illegal values to
> it it would be a different story. But it doesn't, so it isn't.

That also doesn't hold in general. We are able to distinguish even among
typedefs at certain level.

> >> 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.
>
> No, that would imply that the coder was aware of the potential
> problem. The original designer (who implemented the typedef) may be,
> but not necessarily someone adding code.

Using the operator '!!' solves the problem, using s/bool/int/ does _not_ solve
the problem.

> Besides, we write in C, so let's write good C. And using typedefs to
> hide basic C types is not good C programming.

Let's use the _standard_ bool then, whenever possible.

> Ok, I'll try from another direction then.. can anyone point to any
> real-life scenarios where using things like
>
> typedef unsigned char bool

The only advantage is that we can compile the same code on architecture where
the _standard_ bool is not available. However if we have it, then the code is
type-safe.

> has ever turned out to be a design life-safer later in the project?
> Because I can't, and we have 25 years' worth of C code here at work..
> millions of code lines. I can easily point to the oppsite though: That
> it just reduced maintainability and quality.

Then you should probably read the up2date C standard. I remember we discuss
something similar a year ago at bug-coreutils (in the context of mixing '&'
and '|' with '&& and '||') and ended up with the same conclusion:

http://lists.gnu.org/archive/html/bug-coreutils/2008-09/msg00028.html

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