MEM31-C. Free dynamically allocated memory when no longer needed

The C standard doesn't say anything about what happens with a size argument of 0, but I checked glibc and openbsd source real quick and they appear to return a valid pointer to a zero-sized object.. e.g. the return of a malloc(0);

I mention this because if there was a system where realloc() free'ed the object and then returned NULL, it would make the secure idiom for realloc() exploitable. Here's that idiom, snagged from an openbsd man page:

if ((p2 = realloc(p, nsize)) == NULL) {
    if (p)
        free(p);
    p = NULL;
    return NULL;
}
p = p2; 

You can see that if nsize was 0, and realloc() free'ed the memory and then returned NULL, it would be a double-free of p. I would guess that no systems actually do this, but it might be worth researching. As it stands, the behavior with an nsize of 0 is pretty interesting and counter-intuitive, and I can see people running into trouble because of it.

The document assumes C99 - even if it only assumed C89, free(0) is defined as safe.  It is only pre-C89 implementations that might have the problem.  Presumably, those who work on such implementations are aware of the problems, and for the large majority who do not work on such archaic systems, there is no issue.

I think you are referring to code that does the following:

/* ... */
if (error_condition == 1) {
  /* handle error condition*/
  free(x);
  x = NULL;
  return; /* or transfer control, such as abort() or goto */
}
/* ... */
free(x);
x = NULL;

This code clearly frees x just once, and so complies with the rule, but this code has the following drawbacks:

• Its harder to specify. Just saying 'return' is invalid if the code is inside a non-void function.
• Its easier to modify the code such that the return is deleted, which turns the code back into the NCCE.
• The cleanup of x is duplicated inside & outside the if statement. The redundancy leads to code bloat and potential for more errors.

I suspect these reasons are why this code sample wasn't included as a 2nd CS.

I wonder if MEM08-C. Use realloc() only to resize dynamically allocated arrays could be tweaked to cover the case you mention. As it stands, the problem MEM08-C tries to avoid doesn't seem like one that's specific to realloc() but rather one of converting a pointer to one object to a pointer of an unrelated type. That can just as easily happen with malloc() or in any other situation involving a cast of a pointer to another.

Even when replaced, the Risk Assessment needs attention.

Severity on this page is "Medium".  But summary on the "Memory Management" page shows Severity for this rule to be "High".  The two should align.

While not strictly needed, it's commonly viewed as a best practice to do the cast. See MEM02-C. Immediately cast the result of a memory allocation function call into a pointer to the allocated type for more information.

I support this and would point out that EX1 is providing basically this exact exception already (it can likely be reworded to make this more clear, however). It may need some weasel words about verifying that the host OS cleans up memory on program termination to cover embedded systems which may not behave the same way as desktop systems.

What is this 'putenv'? That be one of them new-fangled POSIX functions? It aint no C standard function, podner.

More seriously, what constraints does putenv() impose on its argument? Does it copy the argument contents, or does it require the argument's lifetime to last the life of the program (or until the env var is overwritten).
There is certainly some guideline you could write about safe use of putenv, but it belongs in the POSIX section.