On 5/29/2012 8:56 PM, Jeremy Farrell wrote:
From: Jakob Bohm [mailto:jb-open...@wisemo.com]
Sent: Tuesday, May 29, 2012 8:34 AM
On 5/27/2012 2:29 AM, Jeremy Farrell wrote:
From: Jakob Bohm [mailto:jb-open...@wisemo.com]
On 5/25/2012 5:30 PM, Ken Goldman wrote:
On 5/25/2012 3:33 AM, Jakob Bohm wrote:
ANSI C and POSIX free() is NOT required to handle free(NULL)
as a NOP.
I checked reputable sources (Plauger, Harbison and Steele, the ANSI
spec, and the IEEE POSIX spec).
All agree that (e.g. ANSI)
"If ptr is a null pointer, no action occurs."
Which version of the ANSI Spec, and where did you get a copy?
I quoted from C99 in a recent message; can't remember where I got it
(12 years ago ...), perhaps Techstreet. There are 'final drafts' of C99
and C11 legally available for free on the web I believe.
Various revisions of POSIX are available free for reference online;
the current POSIX.1-2008 at
http://pubs.opengroup.org/onlinepubs/9699919799/ and the older POSIX.1-
2004 at http://pubs.opengroup.org/onlinepubs/009695399/
Note that when considering portability, C99 is not yet
fully implemented everywhere, so when I say "ANSI C"
without qualification, I generally refer to C89 plus
the two TR update documents that mostly focused on
things many compilers were already doing.
Having no current access to the C89 standard or its
drafts, I am relying on the experience that many "C89"
real world systems I have encountered did not tolerate
free(NULL). In contrast all recent C++ specifications
(starting with The C++ Programming Language 2nd Ed.
which preceded all published standards), insist that
delete (char*)NULL must be a safe NOP.
As C99 adopted many other features from C++ (such as
declarations between statements), the free(NULL)
behavior might also be new in C99.
C99 was what I had most conveniently to hand, but as I mentioned originally the
requirement has been the same in all versions of Standard C from C89 through to
the current C11. C89 has:
4.10.3.2 The free function
Synopsis
#include<stdlib.h>
void free(void *ptr);
Description
The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation. If ptr
is a null pointer, no action occurs. Otherwise, if the argument does
not match a pointer earlier returned by the calloc , malloc , or
realloc function, or if the space has been deallocated by a call to
free or realloc , the behavior is undefined.
Returns
The free function returns no value.
The Rationale for C89 states "The null pointer is specified as a valid argument to
this function to reduce the need for special-case coding".
Other standards documents of the time (XPG3, for example) mention adding the
sentence on NULL for conformance with the draft C Standard, so it looks like the
ANSI C committee was the driver for explicitly requiring this behaviour; I don't
know if any earlier implementations worked that way, K&R 1 didn't mention the
free library function. I don't know C++, but Stroustrup's site says C++ 2 was
written in '91, so he'd be assuming the C89 library as the basis.
In the early days of C++, Stroustrup was also closely involved in the
work that became C89. In one of his books, he has taken partial credit
for the const keyword.
Some of the "NULL not accepted" free routines I have come across were
slightly outside the basic C runtime (such as underlying OS memory
allocators), so adding the special casing for NULL (or other false)
pointers has been deeply engrained in my coding habits for long enough
that I may not have noticed if most libc implementations did their own
checking and NOP-ing too.
I also started coding before 1989, although didn't learn C until after
'89, so I may have learned from existing K&R compatible code (It is kind
of sad that recent compilers have dropped the K&R parsing option, it was
kind of cute).
I'm a bit surprised you've come across systems at all recently which don't
tolerate free of NULL. I've tended to assume they do without explicitly testing
it (I'm fool enough to rely blindly on standards for some things), but I would
usually only make such a call in unusual error paths; I guess it may come back
to bite me sometime.
Regards,
jjf
--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
<call:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
