42init memory allocations using "calloc"

[bobvogt314159]

Dear Eric.

Thank you for all of the effort you have put into this platform.

I have been utilizing 42 for a number of years (over 3 years) and have just noticed some strange behavior related to initialization, reading in the "Spacecraft" files. In particular the problems are related, but not necessarily caused by the allocation of memory if there are "zero" items specified (i.e., number of mtbs, etc.). The code pushes ahead and allocates memory even if the value of "N" is zero. Here is an example from 42init.c:

  S->Whl = (struct WhlType *) calloc(S->Nw,sizeof(struct WhlType));

I have added many new sensors to the code but tried to follow your existing code exactly. I recently had problems with a new sensor when I originally had "N" equal 2, and later decreased this to 1 and updated the file accordingly. I got this error message.

malloc(): unsorted double linked list corrupted

This occurred in InitRigidDyn when allocating D->ConnectTable

The problem was then clear up by arbitrarily setting another sensor "N" from 0 to 1.

My correspondence here is not to ask you to troubleshoot issues I have likely created.

My question is, however, about the use of calloc. There is some information out on the web that recommends against allocating "zero" memory, which is done in 42init.c every time there is a value of "N" that is zero. Has this been an issue for you? It would be easy to do a check of N==0 and bypass the calloc call. However, this could easily break other things.

Suggestions?

Thanks for your time

Bob

[ericstoneking]

Hi Bob,

Thanks for the interesting question. A few minutes of internet research suggests that calloc-ing zero bytes results in "implementation-specific" behavior: some compilers might assign NULL, while others might assign a non-null address. The user is expected to refrain from trying to access that memory in either case.

The way I use these calloc-ed arrays tends to be in a loop, such that zero-length arrays get accessed zero times, as in:

for(i=0;i<S->Nwhl;i++) S->Whl[i].H = 0.0;

If Nwhl = 0, the fact that S->Whl[i] points to who-knows-where is not a problem since iNwhl is never true.

As you suggest, I could easily protect each calloc with an if(N==0) Pointer = NULL else Pointer = calloc(N,sizeof(foo)); This wouldn't change anything for me. If it breaks something someone else is doing, they've probably voided the warranty anyway. Crashing on a NULL pointer might be an easier behavior to diagnose than whatever happens accessing a non-null pointer.

I know there are some lurkers here who are savvier coders than I am. Let's see if they'll weigh in. I'll take the action to put in the N==0 protection, but with low urgency. If anyone reading this either thinks it should be urgent, or sees a downside to it that I don't, let's hear it.

Regards,
-Eric