From owner-freebsd-hackers Sat Feb 24 23:57:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id B1F2E37B401 for ; Sat, 24 Feb 2001 23:57:28 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1P7vR625246 for ; Sun, 25 Feb 2001 01:57:27 -0600 (CST) Message-Id: <200102250757.f1P7vR625246@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sun, 25 Feb 2001 00:45:25 MST." <200102250745.f1P7jPd02969@harmony.village.org> Date: Sun, 25 Feb 2001 01:57:27 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102250745.f1P7jPd02969@harmony.village.org>, Warner Losh writes: >I do not believe you. Such a "believe" does not appear to be embodied >in the C-99 standard. It's somewhat debated, but it has come up in discussions, and the consensus is that, if malloc returns a pointer, the memory has to be usable. >Notice that no guarantees about the ability to use all the space, or >that it is somehow guaranteed to be there. That's what space *is*. Space is something that can store values. If it can't actually store values, it's not space. >space is allocated. Nothing more and nothing less. I defy you to >quote me someting from the standard that is contrary to my position. Heh. >I searched through the standard extensively to see if "allocates >space" is defined and couldn't find anything other than 'the poitner >can be used to access the space allocated.' EXACTLY! If it can't actually be used, then something has gone horribly wrong. >There appear to be no >guarantees that you can always use all of the memory that you've >allocated, the performance characterstics of accessing said memory or >anything else. Performance characteristics are not at issue; I don't think anyone on the committee would complain about an implementation which provided "committed" space by backing it all to disk, all the time. >Do not read too much into the above words. They mean exactly what >they say. FreeBSD is in compliance. Assuming I make the Copenhagen meeting, I'll bring this up again as a DR or something. This gets debated every few years, and the consensus seems to be that malloc *MUST* return a valid pointer to space which can actually be used. >The space is indeed allocated to >the process address space. System resource issues might get in the >way of being able to use that, but that's true of anything you >allocate. That's not what "allocate" means. A resource which is *allocated* is one you actually have access to. Basically, if your interpretation had been intended, the committee would have put in words to the effect of "access to an allocated object invokes undefined behavior". It doesn't. Therefore, the following code: #include int main(void) { unsigned char *p; if (200000000 < SIZE_MAX) { p = malloc(200000000) if (p) { size_t i; for (i = 0; i < 200000000; ++i) { p[i] = i % 5; } } } return 0; } *MUST* succeed and return 0. The program does not invoke undefined behavior; therefore, the compiler is obliged to ensure that it succeeds. It's fine for malloc to fail; it's not fine for the loop to segfault. This is probably one of the single most-unimplemented features in the spec, but it really wouldn't be that hard to provide as an option. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message