[EMAIL PROTECTED] writes: > For example IIRC the specs don't define what free((void *)0) should > do, so it can either return cleanly doing nothing or cause a > segmentation fault depending on the compiler.
Or send an email to your manager suggesting that your salary should be revised. It may be done by the same implementation that usually does nothing when you free(0), depending on the value of a trancendental function of the phase of the moon and the PID of your program. In general, I think this thread tends to mix undefined and unspecified behavior, so let's introduce some order into the issue. Undefined behavior is exactly that - *anything* at all can happen. More specifically, an implementation may behave unpredictably. Including sending an email to your boss, though it may not seem as a reasonable implementation of freeing NULL or writing past a buffer boundary or whatever. Note that one possibility is that the statement that is technically undefined will perform "reasonably" but the rest of the program won't. The program will do nothing when it gets to free(NULL) but will print "you are a moron" from a totally different function that does not do any IO at all. Unspecified behavior is one that is consistent and documented by a particular implementation. Usually unspecified behavior is allowed for efficiency reasons etc. Examples include the size of an int or a pointer, whether char is signed or unsigned, etc. You should worry about unspecified behavior if you care about portability (ints are guaranteed to be of the same size on your platform). You should worry about undefined behavior even if you don't care about portability (don't free(NULL) ever). For more (authoritative) information see the C FAQ #11.33. -- Oleg Goldshmidt | [EMAIL PROTECTED] | http://www.goldshmidt.org ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
