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: Akim Demaille
Subject: Re: bug(s) in 2.5.19 skel.c
Date: 17 Sep 2002 13:27:49 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

>>>>> "Hans-Bernhard" == Hans-Bernhard Broeker <address@hidden> writes:

Hans-Bernhard> On Mon, 16 Sep 2002, Bruce Lilly wrote:
>> 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.

Hans-Bernhard> Wrong.  There definitely is a problem, and particularly
Hans-Bernhard> with pointers.  Calling memset() or calloc() creates
Hans-Bernhard> "all bytes zero".  Which may seem to be equivalent to
Hans-Bernhard> "value zero" for the NULL pointer --- but it isn't,
Hans-Bernhard> because there is no fixed predefined mapping between
Hans-Bernhard> pointers and integers, including the integer zero. To
Hans-Bernhard> isolate the point: after

Hans-Bernhard>  whatever * pointer; memset(&pointer, 0,
Hans-Bernhard> sizeof(pointer))

Hans-Bernhard> it is *not* reliably guaranteed that

Hans-Bernhard>  pointer == 0; or pointer == NULL;

Hans-Bernhard> holds.  Actually, both of these comparisons cause
Hans-Bernhard> undefined behaviour.  Read the C FAQ if you don't trust
Hans-Bernhard> my words, or at least re-check the extract I quoted
Hans-Bernhard> from it.

This is very true theoretically, but I never saw evidence of practical
existence.  This is looking for additional burden where there is,
IMHO, already enough to think about.  For instance, test snippets from
Autoconf do assume NULL == 0, and there has never been any bug
report.




reply via email to

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