[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug(s) in 2.5.19 skel.c
From: |
Bruce Lilly |
Subject: |
Re: bug(s) in 2.5.19 skel.c |
Date: |
Mon, 16 Sep 2002 15:02:51 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 |
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.
- bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/14
- Re: bug(s) in 2.5.19 skel.c, John Millaway, 2002/09/15
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/15
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/15
- Re: bug(s) in 2.5.19 skel.c, John Millaway, 2002/09/15
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/16
- Re: bug(s) in 2.5.19 skel.c, John Millaway, 2002/09/16
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/16
- Re: bug(s) in 2.5.19 skel.c, John Millaway, 2002/09/16
- Re: bug(s) in 2.5.19 skel.c,
Bruce Lilly <=
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Akim Demaille, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Akim Demaille, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/17