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
Am Sonntag, den 20.04.2008, 09:34 -0700 schrieb Jon Sargeant:> 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.It is indeed analogous, and using 0 for an invalid pointer can break in rare circumstances, too. (E.g. the x86 interrupt table is at address 0. On the 68000, 0 can even be perfectly valid heap memory.) Using special values to signify special conditions is usually a Bad Idea (TM). It is also ubiquitous, probably promoted by weak union support in C (actually in most languages).> >> 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 agree, but "very unlikely" is not the same as "impossible". I.e. if it's just "very unlikely", this means there *will* be cases where restricting the count to unsigned is unfortunate. You don't even lose your assertion printing capability. Just have the allocator check whether that much space is available - that's even better than catching nominally negative values, because it will also catch those situations where the program erroneously allocates just a quarter of the address space.> >> 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.Just look at any part of news:comp.lang.functional and you'll see the exact opposite sentiment. Arguments by majority aren't entirely irrelevant, but they are weak, and stronger arguments have been given already. Considering that C++'s support for tagged unions is just marginally better than that of C, I don't think that comp.lang.c++.moderated is the right place to look for an unbiased view when it comes to designing interfaces that should serve many languages. [*] To see the other side of the fence, take any introductory text on the Haskell language and look for "pattern matching". At its core, it's a way to return multiple values from a function without the syntactic overhead. This opens the possibility to return multiple pieces of information without having to cram them into a single scalar. Regards, Jo [*] If we've been talking about the allocation for the LLVM library itself, then my point is moot since all code that uses the interface is C++ anyway, and I apologize for getting off-topic.
>>>> 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. > > Just look at any part of news:comp.lang.functional and you'll see the > exact opposite sentiment. > > Arguments by majority aren't entirely irrelevant, but they are weak, and > stronger arguments have been given already.<snip> You've missed the point. I habitually use signed integers for counts, so naturally, I assumed that NumElements was signed, and I wondered what would happen if NumElements was negative. It was only after asking Chris that I discovered that NumElements was unsigned. Since many other people habitually use signed integers for counts, many other people might make the same mistaken assumption when reading the LLVM documentation. Best Regards, Jon
On Sun, Apr 20, 2008 at 9:34 AM, Jon Sargeant <delta17 at cox.net> wrote:> Perhaps, but very unlikely. An allocation of 2 gigabytes or more is > probably a bug.I don't have a strong opinion on this thread, I just wanted to point out that I have on several occasions allocated more than 2 GB of memory. I can think of a numerous apps I have worked on tangentially which (off the top of my head) probably have some allocations in that range. I'd like to keep 32bits of room in my allocations. 63 bits is plenty for me though, hence my lack of strong opinion. =D One bit is about the right size for a boolean flag "broken". -Chandler> > > >> 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080421/c78ed6a9/attachment.html>