Re: bug(s) in 2.5.19 skel.c

[Bruce Lilly]

Hans-Bernhard Broeker wrote:
> 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.

In the specific case of the flex code, the problem was
that a pointer was tested via the code snippet:

        if ( ! YY_G(yy_state_buf) )
            YY_G(yy_state_buf) = malloc(YY_BUF_SIZE + 2  );

whereas the pointer YY_G(yy_state_buf) had never been
initialized to a null pointer.

There is not even a theoretical problem with calloc or
memset there, as ANSI/ISO C section 6.2.2.3 clearly states
that a null pointer has value 0.

If one wished to be pedantic, one could claim
that the conditional in the test should be

        YY_G(yy_state_buf) != NULL

but in reality, the requirement of section 6.2.2.3
means that the existing conditional is always correct.

The implementation-dependent nature of the
NULL macro (as distinct from the clearly-defined value of
a null pointer constant) is that the macro might be
defined in slightly different ways, e.g. w/ or w/o a
L suffix.

Regarding integral types, the requirements of ANSI/ISO C
section 6.1.2.5 means that for all practical purposes
a zero valued integer of any size will be all zero bits,
and efficient implementation of bit fields (6.5.2.1)
virtually guarantees it.

That leaves floating point types as a potential problem,
but there aren't any of those in the flex structure
under discussion.