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. _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
