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
Jon Sargeant wrote:> 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.In C malloc() takes an unsigned parameter. For example on x86-32 Linux I can allocate with malloc at most 4022034420 bytes (which would otherwise be a signed value). Since LLVM's malloc intrinsic can be used to replace a malloc call, I think it should behave the same. However alloca() would most certainly overflow the stack with such a large allocation, and I think allocating >2G with alloca() can be treated as undefined. Best regards, --Edwin
Am Samstag, den 19.04.2008, 16:24 -0700 schrieb Jon Sargeant:> First, I can assign -1 to > the count to indicate an invalid or unknown value.This is a C-ism. In a language that supports discriminated unions well, you'd do something like type AllocaCount = Invalid | Unknown | Known int (where Invalid, Unknown and Known are the constants that do the distinction between union variants).> 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.Which might be exactly what it's supposed to do. Suppose you're writing heap management code.> I'm not necessarily saying that NumElements should be > signed, only that the choice between signed and unsigned is not obvious.Obviously, obviousness is in the eye of the beholder :-) (SCNR) Regards, Jo
Joachim Durchholz wrote:> Am Samstag, den 19.04.2008, 16:24 -0700 schrieb Jon Sargeant: >> First, I can assign -1 to >> the count to indicate an invalid or unknown value. > > This is a C-ism. In a language that supports discriminated unions well, > you'd do something like > type AllocaCount = Invalid | Unknown | Known int > (where Invalid, Unknown and Known are the constants that do the > distinction between union variants).Not necessarily. Using -1 for an invalid integer is analogous to using null for an invalid pointer.>> 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. > > Which might be exactly what it's supposed to do. Suppose you're writing > heap management code.Perhaps, but very unlikely. An allocation of 2 gigabytes or more is probably a bug.>> I'm not necessarily saying that NumElements should be >> signed, only that the choice between signed and unsigned is not obvious. > > Obviously, obviousness is in the eye of the beholder :-) > (SCNR)Yes. But consider that there are many people who agree with me. Search for "unsigned vs signed - Is Bjarne Mistaken?" in comp.lang.c++.moderated. Best Regards, Jon