Anton Bobrov wrote:
Hmm - you're right. I've checked HP/ux 11.23, Solaris 9, and various
versions of RHEL and Fedora Core, and they all say that. Is this the
behavior of POSIX free()? Or is there some other standard that
covers the behavior of free() (C99)?
its like that since ANSI C i guess, at least K&R second edition ANSI C
book i have defines "does nothing if the pointer is null" for free().
Our code is full of defensive programming against free'ing NULL. I
know in years past free(NULL) used to cause a segfault on some
platforms, or abort on others. Do you know if free() behaves this
way on Windows and Mac?
its the same way on MacOS and Windows. for MacOS i can tell you it was
like that even before FreeBSD derived MacOSX and i think its long like
that in Windows as well.
what i dont get is why this being brought up here? the code in question
is harmless, in fact it offers certain optimization by saving one or
more [ depending on implementation and optimizations used ] enter/exit
sequences when calling to free(). its cheaper to check if the pointer
is null from inside that code than to call to free() and check it from
there. not that it matters either given the function in question isnt
called frequently enough to make any real performance difference. say
leave it like that and forget about it.
Keep in mind that (a) a frequently used function like free() is likely to be
in the cache, and (b) duplicating the NULL check done inside free()
causes unnecessary bloat... which is an issue in embedded environments
where you don't always have a lot of memory.
I was pointing it out because there are other places that free() gets called
that is bracketed with an unnecessary NULL check.
-Philip
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap
