On Tue, May 25, 2010 at 21:24, Kamil Dudka <kdudka_at_redhat.com> wrote:
> On Tuesday 25 of May 2010 11:33:39 Tor Arntsen wrote:

>> 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.

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();
(You may think that the above wouldn't greate trouble unless the
function returns a value higher than 255, but that's not the case, as
the 577 problem showed. It's just that what happens depend on the
compiler and the architecture. In this case, big endian and a couple
of native compilers. And the other day (at work) I came across a
function parameter-trashing problem which was also caused by an
apparent innocent-looking mix of char and int.. With gcc, on x86. No
compiler warnings.)

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.

Use typedefs for things like
typedef struct {
..
} my_type_t;
etc. That makes some sense, at least.

[..]

>> 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.

[..]
> 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.

We write in C, we use a C compiler. That's what we have. I don't
remember if it was the libcurl project or some other project I was in
touch with that at some point tried to massage the code so that it
could be compiled with a C++ compiler, to better catch things like
typedef problems. But such efforts always end up in bitrot, it's too
hard to maintain.
Besides, we write in C, so let's write good C. And using typedefs to
hide basic C types is not good C programming.

[..]
> 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.

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

typedef unsigned char bool

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.

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