Note that there are some explanatory texts on larger screens.

plurals
  1. POWhats the use of zero sized memblocks?
    text
    copied!<p>By the worry of my last days/weeks when I figured out that much of my code does break c99 rules, what is leading into undefined behaviour, I started explicitly reading the ISO/IEC 9899:TC3 draft paper. Especially the Appendix "J.2 Undefined behaviour" The most of it was logical to me why it could be hard to compile code that's breaking those rules, or at some cases I could at least think "well, I don't get it, what's the problem with that, but I 'shall' do it that way" but there is one point... </p> <blockquote> <p>"A non-null pointer returned by a call to the calloc, malloc, or realloc function with a zero requested size is used to access an object (7.20.3)."</p> </blockquote> <p>(for all who haven't read ISO/IEC 9899:TC3 "J.2 Undefined behaviour", this section just explains which cases will run into undefined behaviour).</p> <p>So there are so many Questions in my head about that case.</p> <p>First of all:</p> <p>Why should I want to allocate a memory-block of zero size?</p> <p>And when I have got such a block, what can I do with it?</p> <p>With the aim of avoiding undefined behaviours, probably I don't want to access the memory its pointing to...</p> <p>So I did a bit more research.... looked for some different malloc() man pages. and found out in the Linux malloc(3) man:</p> <blockquote> <p>"If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free()."</p> </blockquote> <p>Well the only thing this helped me with was: I got now additional questions to you and myself. The case that function call with identical parameters under identical conditions may return different results isn't that hard to imagine, OK... but those different results mostly don't have to be tread that different. Thats what lets me suggesting, a non-null pointer to a requested zero size block could just be a unwanted side-effect. Does this mean </p> <pre><code>if ((void *ptr = malloc (0)) == NULL) { /*...*/ } </code></pre> <p>this isn't enough? do I have to handle *alloc calls like this?</p> <pre><code>if (X &lt;= 0) { if ((*ptr = malloc (X)) != NULL) { exit (*); } else { /*...*/ } } else { if ((*ptr = malloc (X)) == NULL) { /*...*/ } } </code></pre> <p>But even if its expected, to get such an </p> <blockquote> <p>"unique pointer value that can later be successfully passed to free()"</p> </blockquote> <p>, how to work with it? I could change it around OK... I'm even allowed to free it (BTW does it mean I HAVE to free it as I should do with every other allocated memory too, or is it just an >you are allowed to, to don't break your code flow <p>what would be the difference to just make any pointer like this?</p> <pre><code>void *X = (void *)"1234abc"; </code></pre> <p>I hope any one can help me with that philosophy of science or is even better as interested as I'm, in it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload