Thanks for your reply. Chris Lattner wrote:>> Regarding free, I also think your wording isn't clear enough: "If the >> pointer is null, the result is undefined." The free result is void. >> Consider rewording as "If the pointer is null, the operation is valid >> but does not free the pointer." > > It isn't though. free(NULL) could segfault the app, for example.See Nick's post.>> Regarding malloc and alloca, I realized that the size is unsigned, >> so a >> negative value for NumElements is impossible. I suggest replacing "it >> is the number of elements allocated" with "it is the UNSIGNED number >> of >> elements allocated". > > I'm not sure why this is more clear.The semantics of malloc and alloca depend on whether you interpret NumElements as a signed or unsigned 32-bit integer. For example, if NumElements is 0xffffFFFF, should the instruction fail (because allocating a negative number of elements doesn't make sense), or should the instruction allocate 2^32-1 elements? I don't see any mention of whether NumElements is signed or unsigned in the documentation.>> I'm working on another set of changes now. If it's not too much >> trouble, it would be more convenient for me to post the changes (as >> I've >> done in this e-mail) and let you integrate them into LangRef.html. > > It would definitely be easier to integrate in patch form. Here is > what I committed: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061277.htmlVery well. I'll submit future changes as patches. Best Regards, Jon
On Apr 19, 2008, at 3:27 PM, Jon Sargeant wrote:>>> Regarding malloc and alloca, I realized that the size is unsigned, >>> so a >>> negative value for NumElements is impossible. I suggest replacing >>> "it >>> is the number of elements allocated" with "it is the UNSIGNED number >>> of >>> elements allocated". >> >> I'm not sure why this is more clear. > > The semantics of malloc and alloca depend on whether you interpret > NumElements as a signed or unsigned 32-bit integer. For example, if > NumElements is 0xffffFFFF, should the instruction fail (because > allocating a negative number of elements doesn't make sense), or > should > the instruction allocate 2^32-1 elements? I don't see any mention of > whether NumElements is signed or unsigned in the documentation.How could an element count be treated as negative? It doesn't make sense to allocate negative elements. -Chris
Chris Lattner wrote:> On Apr 19, 2008, at 3:27 PM, Jon Sargeant wrote: >>>> Regarding malloc and alloca, I realized that the size is unsigned, >>>> so a >>>> negative value for NumElements is impossible. I suggest replacing >>>> "it >>>> is the number of elements allocated" with "it is the UNSIGNED number >>>> of >>>> elements allocated". >>> I'm not sure why this is more clear. >> The semantics of malloc and alloca depend on whether you interpret >> NumElements as a signed or unsigned 32-bit integer. For example, if >> NumElements is 0xffffFFFF, should the instruction fail (because >> allocating a negative number of elements doesn't make sense), or >> should >> the instruction allocate 2^32-1 elements? I don't see any mention of >> whether NumElements is signed or unsigned in the documentation. > > How could an element count be treated as negative? It doesn't make > sense to allocate negative elements.True, but making NumElements unsigned just because it can never have a negative value is not obvious. I always use signed integers for nonnegative counts for a couple of reasons. First, I can assign -1 to the count to indicate an invalid or unknown value. Second, if I attempt to allocate a negative count, I can print an assertion failure and abort the program. Had I interpreted the count as an unsigned value, the program would attempt to allocate anywhere from 2 gigabytes to 4 gigabytes. I'm not necessarily saying that NumElements should be signed, only that the choice between signed and unsigned is not obvious. Best Regards, Jon