Date: Sun, 25 Feb 2001 01:57:27 -0600 From: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. Message-ID: <200102250757.f1P7vR625246@guild.plethora.net> In-Reply-To: Your message of "Sun, 25 Feb 2001 00:45:25 MST." <200102250745.f1P7jPd02969@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <stdlib.h>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102250757.f1P7vR625246>