help-flex
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug(s) in 2.5.19 skel.c


From: Hans-Bernhard Broeker
Subject: Re: bug(s) in 2.5.19 skel.c
Date: Mon, 16 Sep 2002 15:39:34 +0200 (MET DST)

On Mon, 16 Sep 2002, John Millaway wrote:

> Interesting. Can you give an example where this would fail?
> (Currently, we do both:  memset after allocation, then assign to
> zero/NULL during initialization.)

It's more of a theoretical threat, but a well-known one among those.

To cite parts of the C FAQ:

Question 1.30:
[...]
        initialized by the calling program, as appropriate.  Memory
        obtained with calloc() is all-bits-0, but this is not
        necessarily useful for pointer or floating-point values (see
        question 7.31, and section 5).

and in the (draft) C9x standard, we find this, in section 6.2.6.1
on "Representations of types --- general":

       [#5] Certain object representations  need  not  represent  a
       value  of the object type.  If the stored value of an object
       has such a representation  and  is  accessed  by  an  lvalue
       expression  that  does not have character type, the behavior
       is undefined.  If such a representation  is  produced  by  a
       side  effect  that modifies all or any part of the object by
       an lvalue expression that does not have character type,  the
       behavior is undefined.37)  Such a representation is called a
       trap representation.

These "certain objects" can exist in any type other than unsigned char.  
Only for the latter does the C standard require a "pure binary
representation", i.e. exactly as many bits used as the value range
actually needs, and no traps.  I.e. loading all-bits-zero into any
variable of type other than unsigned char and accessing the variable
afterwards is allowed to cause undifined behaviour --- a program crash,
nasal demons, or whatever other evil you can imagine.

Of course the problem doesn't exist on any of the usual platforms we're
all developing code on, like the Intel PC or any other similarly
VAX-o-centric ones with IEEE floats and an all-bits-zero NULL pointer.
That's why hardly anyone cares about or even notices it.  But for code
aiming to be ultimately portable, this is not something you can rely upon.

> > did you consider using a tool like 'cscope' to that end? 
> Yes, it's built into my editor (ViM).  `nm' does the trick, too.

So how did they fail, to make you say you "don't have a suitable method"
for doing this (or whatever --- forgot the exact wording).

-- 
Hans-Bernhard Broeker (address@hidden)
Even if all the snow were burnt, ashes would remain.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]