For your collective amusement, here's a post that talks about how OS/2 handles
memory allocation. DosAllocMem() has a flags argument, and one of the flags
requests the OS to actually commit the memory.
http://w3.hethmon.com/os2isp/1998/Apr/Msgs/l2w96957.html
http://www.stidolph.com/os2ap
On Tue, Feb 27, 2001 at 10:39:13PM -0800, Julian Elischer wrote:
> no, something specifically designed around kernel type of actions.
> declarations of "physical pointer", "kvm pointer" "User Pointer"
> for example, and being able to declare a structure (not 'struct')
> and say "this list is 'per
Tony Finch <[EMAIL PROTECTED]> writes:
> What about setrlimit(RLIMIMT_DATA)?
Yep, I'd forgotten about that. Malloc() will return NULL if you hit
your data size limit.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers
Matt Dillon wrote:
> Allowing a program to run the OS itself out of VM, with or without
> overcommit, is (being generous) just plain dumb.
I'm not a fan of either (overcommit or non-), I can see advantages with both
(seeing that Solaris, which I happen to work with, has one and FreeBSD t
Wes Peters wrote:
>
> Julian Elischer wrote:
> >
> > Arun Sharma wrote:
> > >
> > > On 26 Feb 2001 18:56:18 +0100, Matt Dillon <[EMAIL PROTECTED]> wrote:
> > > > Ha. Right. Go through any piece of significant code and just see how
> > > > much goes flying out the window because the code
Julian Elischer wrote:
>
> Arun Sharma wrote:
> >
> > On 26 Feb 2001 18:56:18 +0100, Matt Dillon <[EMAIL PROTECTED]> wrote:
> > > Ha. Right. Go through any piece of significant code and just see how
> > > much goes flying out the window because the code wants to simply assume
> > >
Maxime Henrion <[EMAIL PROTECTED]> wrote:
>Tony Finch wrote:
>>
>> If it's available at all, mprotect() is often limited to memory
>> obtained with mmap(), i.e. not malloc(). Not great for portability.
>
>FreeBSD malloc() calls mmap() as AFAIK many (if not all) malloc()
>implementations.
FreeBSD
Tony Finch wrote:
> Drew Eckhardt <[EMAIL PROTECTED]> wrote:
> >In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
> >>In most cases it is impossible to declare the data read-only because
> >>it originally had to be read-write and you can't change its attributes
> >>later.
> >
> >mprotect(
Drew Eckhardt <[EMAIL PROTECTED]> wrote:
>In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>>In most cases it is impossible to declare the data read-only because
>>it originally had to be read-write and you can't change its attributes
>>later.
>
>mprotect(2).
If it's available at all, m
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>In most cases it is impossible to declare the data read-only because
>it originally had to be read-write and you can't change its attributes
>later.
mprotect(2).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
Lyndon Nerenberg <[EMAIL PROTECTED]> wrote:
>
>If the information in the data segment is going to be updated then
>you have to have writable backing store. If, however, that data
>is never going to be changed, it should be declared in the program
>as read-only data. The kernel VM system should not
Tony Finch wrote:
>
> >It doesn't trash. The memory is filled with backtracking information.
> >Memory in active use at any time is rather small.
>
> I've read articles about programs which use GC which have a small
> working set, although it is constantly changing (I've heard of
> programs allo
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
>Matt Dillon wrote:
>>
>> What is the point of running a scientific calculation if the
>> machine turns into a sludge pile and would otherwise cause the
>> calculation to take years to complete instead of days?
>
>It doesn't trash. The memo
> "Tony" == Tony Finch <[EMAIL PROTECTED]> writes:
>> Well, to some extent, I have to wonder why all these pages are
>> being requested if they aren't being used...
Tony> fork() with big data segments that cause swap to be reserved
Tony> in case of a copy-on-write. The 2GB o
Peter Seebach <[EMAIL PROTECTED]> wrote:
>David Gilbert writes:
>>
>>Due to the bloat of the OS and Motif and other such things, they
>>required simply amazing amounts of swap just to run.
>
>Well, to some extent, I have to wonder why all these pages are being
>requested if they aren't being used.
Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
>
>This is all academic since FreeBSD does memory overcommit, so unless
>you run out of address space for your process before you run out of
>actual memory and/or swap (not likely, but quite possible) malloc()
>will never return NULL and you won't kno
Peter Seebach wrote:
...
> Imagine a word processor with this behavior. No attempt to save your
> file, no nothing, it just suddenly closes all windows and dies.
I think most people can think of at least one widely used commerical
word processor with exactly this behaviour. :-)
To Unsubscribe:
Daniel, you don't have to believe me, I really don't care. I hear this
argument once or twice a year and those of who actually have experience
(except for Terry, who always likes to argue theory) already know what
the reality is. Come back in a year or two after you've wasted a t
Arun Sharma wrote:
>
> On 26 Feb 2001 18:56:18 +0100, Matt Dillon <[EMAIL PROTECTED]> wrote:
> > Ha. Right. Go through any piece of significant code and just see how
> > much goes flying out the window because the code wants to simply assume
> > things work. Then try coding conditi
Matt Dillon wrote:
>
> Said application was poorly written, then. Even on solaris if you
The only reason the application was "poorly written" is the overcommit
architecture.
> actually run the system out of memory you can blow up other unrelated
> processes. To depend on that sort
:> things work. Then try coding conditionals all the way through to fix
:> it... and don't forget you need to propogate the error condition back
:> up the procedure chain too so the original caller knows why it failed.
:
:So, it all comes down to reimplementing the UNIX kernel in a l
On 26 Feb 2001 18:56:18 +0100, Matt Dillon <[EMAIL PROTECTED]> wrote:
> Ha. Right. Go through any piece of significant code and just see how
> much goes flying out the window because the code wants to simply assume
> things work. Then try coding conditionals all the way through to f
In message <[EMAIL PROTECTED]>, Tony Finch writes:
>fork() with big data segments that cause swap to be reserved in case
>of a copy-on-write. The 2GB of swap is never actually used, but you
>still have to have it.
That's a good point. So, we should warn people that asking for memory
committments
In message <[EMAIL PROTECTED]>,
Rik van Riel writes:
>Rationale:
>SIGSEGV for _user_ mistakes (process accesses wrong stuff)
>SIGBUS for _system_ errors (ECC error, kernel messes up, ...)
Actually, this is not canonically the distinction made. On a Unix PC,
{
int *a, c[
In message <[EMAIL PROTECTED]>,
Rik van Riel writes:
>I don't think a failed kernel-level allocation after overcommit
>should generate a segfault.
>IMHO it should send a bus error (or a sigkill if the process
>doesn't exit after the SIGBUS).
Same difference, so far as the language is concerned.
On Mon, 26 Feb 2001, Peter Seebach wrote:
> In message <[EMAIL PROTECTED]>,
> >And maybe, just maybe, they'll succeed in getting their
> >idea of non-overcommit working with a patch which doesn't
> >change dozens of places in the kernel and doesn't add
> >any measurable overhead.
>
> If it adds ov
> "Daniel" == Daniel C Sobral <[EMAIL PROTECTED]> writes:
Daniel> Dag-Erling Smorgrav wrote:
>> > > None of these solutions are portable, however; > Well, no, but
>> the sole available definition of "portable" says that it is >
>> "portable" to assume that all the memory malloc can return is
In message <[EMAIL PROTECTED]>,
>And maybe, just maybe, they'll succeed in getting their
>idea of non-overcommit working with a patch which doesn't
>change dozens of places in the kernel and doesn't add
>any measurable overhead.
If it adds overhead, fine, make it a kernel option. :)
Anyway, no
On Tue, 27 Feb 2001, Daniel C. Sobral wrote:
> Matt Dillon wrote:
> > :Matt Dillon wrote:
> > :>
> > :..
> > :> the system runs out of memory, even *with* overcommit protection.
> > :> In fact, all sorts of side effects occur even when the system
> > :...
> > :
> > :That's an assumption.
>
On Sun, 25 Feb 2001, Matt Dillon wrote:
> The problem is a whole lot more complex then you think. Dealing with
> overcommit is not simply counting mapped pages, there are all sorts
> of issues involved. But the biggest gotcha is that putting in
> overcommit protection will not a
In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
>Anyway, these are two very different situations, and comparing them is
>silly.
They are situations in which an application can be killed and has no way
to detect that it is about to do something wrong, and in which there *was*
a correct
:> :...
:> :
:> :That's an assumption.
:>
:> Ha. Right. Go through any piece of significant code and just see how
:> much goes flying out the window because the code wants to simply assume
:> things work. Then try coding conditionals all the way through to fix
:> it... and don
Matt Dillon wrote:
>
> :Matt Dillon wrote:
> :>
> :..
> :> the system runs out of memory, even *with* overcommit protection.
> :> In fact, all sorts of side effects occur even when the system
> :...
> :
> :That's an assumption.
>
> Ha. Right. Go through any piece of significant cod
Peter Seebach wrote:
>
> It's odd that I see lots of people arguing for segfaults killing the process
> accessing memory that has been "successfully" allocated, but no one arguing
> for the process getting killed when it exceeds a disk quota.
Disk quote is an artificial limit. If you remind each
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> This has nothing to do with overcommit in the context it is being
> discussed. In fact, this has nothing to do with OS memory management
> at all -- all garbage collected languages have their own infrastructure
> to determine when memo
>
> I still think that in such a case it should be possible to
> 'test the commitment' by touching all the allocated memory
> while trapping page faults. and fault all your memory from
> 'potential' to 'allocated'. As someone said. it is not sure which program
> when you run out of swap, but I
:Matt Dillon wrote:
:>
:..
:> the system runs out of memory, even *with* overcommit protection.
:> In fact, all sorts of side effects occur even when the system
:...
:
:That's an assumption.
Ha. Right. Go through any piece of significant code and just see how
much goes flying
In message <[EMAIL PROTECTED]>, Nate Williams writes
:
>Again, memory overcommit is only *one* class of bugs that is avoided.
>The phrase "can't see the forest for the trees" jumps to mind. :)
Sure, and likewise, bugs in libc are only one *class* of bugs we can avoid,
but that doesn't mean we don
> >Even in this case, there's no way to prove your code is not going to
> >crash.
>
> Sure. But you can at least prove that all crashes are the result of bugs,
> not merely design "features".
'Proving' something is correct is left as an excercise for the folks who
have way too much time on thei
In message <[EMAIL PROTECTED]>, Nate Williams writes
:
>Even in this case, there's no way to prove your code is not going to
>crash.
Sure. But you can at least prove that all crashes are the result of bugs,
not merely design "features". From the point of view of proving that a
system is designe
[ Memory overcommit ]
> One important way to gain confidence that you're little box won't
> silently crash at the worst possible time for the customer is to
> be able to *prove* to yourself that it can't happen, given certain
> assumptions. Those assumptions usually include things like "the
> har
In message <[EMAIL PROTECTED]>,
Rik van Riel writes:
>> No, I just disagree. It is useful for the OS to provide a hook for
>> memory which is *known to work* - and that is the environment C specifies.
>Send patches.
I may some day. It's not very high on my priority list; I'd probably try to
f
On Sat, 24 Feb 2001, Peter Seebach wrote:
> In message <9820.983050024@critter>, Poul-Henning Kamp writes:
> >I think there is a language thing you don't understand here.
>
> No, I just disagree. It is useful for the OS to provide a hook for
> memory which is *known to work* - and that is the env
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>The problem is a whole lot more complex then you think. Dealing with
>overcommit is not simply counting mapped pages, there are all sorts
>of issues involved. But the biggest gotcha is that putting in
>overcommit protection wil
In message <[EMAIL PROTECTED]>, Julian Elischer writes:
>I still think that in such a case it should be possible to
>'test the commitment' by touching all the allocated memory
>while trapping page faults.
And what do you do if you get one? There's no undo button for SIGSEGV.
Traditionally, you
Matt Dillon wrote:
>
> But its all a crock. It simply isn't possible to gracefully handle
> an out of memory condition. All sorts of side effects occur when
> the system runs out of memory, even *with* overcommit protection.
> In fact, all sorts of side effects occur even when t
:In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
:>OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
:>*wants* that feature to sit down and code it. It won't happen otherwise.
:
:So, out of idle curiousity: If, somewhere down the road, I know the kernel
:well en
:...
:> : merging such a feature?
:>
:> Assuming that it doesn't break anything, that it doesn't introduce a
:> severe performance penalty and works, there would be interest. There
:> are times that this is a desirable feature.
:
:This thread reminds me of what happened when I brought up the sam
Archie Cobbs wrote:
>
> Warner Losh writes:
> > : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
> > : >*wants* that feature to sit down and code it. It won't happen otherwise.
> > :
> > : So, out of idle curiousity: If, somewhere down the road, I know the kernel
> > :
Warner Losh writes:
> : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
> : >*wants* that feature to sit down and code it. It won't happen otherwise.
> :
> : So, out of idle curiousity: If, somewhere down the road, I know the kernel
> : well enough to attempt such a thi
In message <[EMAIL PROTECTED]>, David Gilbert write
s:
>IIRC, Digital-UNIX or OSF-1 ... or whatever it's called now. I seem
>to remember the first Alphas that arrived to a company I worked for
>had this set globally in the OS by default. Due to the bloat of the
>OS and Motif and other such thing
In message <[EMAIL PROTECTED]> Peter Seebach writes:
: In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
: >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
: >*wants* that feature to sit down and code it. It won't happen otherwise.
:
: So, out of idle curiousity:
In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
>OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who
>*wants* that feature to sit down and code it. It won't happen otherwise.
So, out of idle curiousity: If, somewhere down the road, I know the kernel
well enough to
"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> It doesn't work. The application killed by reason of insufficient
> resources is not (necessarily) the one that causes the page fault
> leading to that.
This is arguably a bug which needs to be fixed.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED
Julian Elischer wrote:
>
> to not be caught by surprise,
> simply touch every page after you allocate it.
It doesn't work. The application killed by reason of insufficient
resources is not (necessarily) the one that causes the page fault
leading to that.
Id est, if my application allocates all
Dag-Erling Smorgrav wrote:
>
> > > None of these solutions are portable, however;
> > Well, no, but the sole available definition of "portable" says that it is
> > "portable" to assume that all the memory malloc can return is really
> > available.
>
> Show me a modern OS (excluding real-time and
Dag-Erling Smorgrav wrote:
>
> [EMAIL PROTECTED] (Peter Seebach) writes:
> > Is there any hope that, some day, a setting could be provided where a program
> > could request that malloc *NOT* overcommit? There are programs which would
> > rather know in advance, and clean up, than be killed abrup
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>It says can, not must.
But if it "can be used", and no one says "undefined behavior", then we're
done; no undefined behavior is allowed.
>I disagree with you that you can't overcommit.
>Also, access is ill defined.
It's defined better in C99
In message <[EMAIL PROTECTED]> Peter Seebach writes:
: >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 some
In message <[EMAIL PROTECTED]>, 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.
>Notic
In message <[EMAIL PROTECTED]> Peter Seebach writes:
: In message <9631.983048712@critter>, Poul-Henning Kamp writes:
: >No it is not and it never was.
:
: The C committee believes it is.
I do not believe you. Such a "believe" does not appear to be embodied
in the C-99 standard.
The standard (
Peter Seebach wrote:
>
> In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
> >This is all academic since FreeBSD does memory overcommit, so unless
> >you run out of address space for your process before you run out of
> >actual memory and/or swap (not likely, but quite possible) malloc(
In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
>It doesn't (and I'm very close to using expletives here). On the
>contrary, it tries to always satisfy the application's requests and
>hopes for the best.
Yes, but it could provide a stronger guarantee than it does.
>It's quite possibl
[EMAIL PROTECTED] (Peter Seebach) writes:
> In message <9877.983050267@critter>, Poul-Henning Kamp writes:
> > And just how will the OS know that a particular memory chip will not
> > generate an uncorrectable ECC error ?
> It can't, but that's no reason for the OS to *add* reasons for failures.
In message <9877.983050267@critter>, Poul-Henning Kamp writes:
>And just how will the OS know that a particular memory chip will not
>generate an uncorrectable ECC error ?
It can't, but that's no reason for the OS to *add* reasons for failures.
-s
To Unsubscribe: send mail to [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, Peter Seebach writes
:
>In message <9820.983050024@critter>, Poul-Henning Kamp writes:
>>I think there is a language thing you don't understand here.
>
>No, I just disagree. It is useful for the OS to provide a hook for
>memory which is *known to work* - and that i
In message <9820.983050024@critter>, Poul-Henning Kamp writes:
>I think there is a language thing you don't understand here.
No, I just disagree. It is useful for the OS to provide a hook for
memory which is *known to work* - and that is the environment C specifies.
-s
To Unsubscribe: send mai
In message <[EMAIL PROTECTED]>, Peter Seebach writes
:
>In message <9631.983048712@critter>, Poul-Henning Kamp writes:
>>No it is not and it never was.
>
>The C committee believes it is.
The C committee doesn't deal with operating systems or the real world
for that matter. They only interest the
In message <9631.983048712@critter>, Poul-Henning Kamp writes:
>No it is not and it never was.
The C committee believes it is.
-s
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In message <[EMAIL PROTECTED]>, Peter Seebach writes
:
>In message <9469.983047707@critter>, Poul-Henning Kamp writes:
>>The guarantee is "If malloc returns NULL there is no memory you can use".
>
>No, it's "if the memory is not available, malloc returns NULL".
No it is not and it never was.
See
Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Peter Seebach writes
> :
> >In message <9402.983047348@critter>, Poul-Henning Kamp writes:
> >>>Well, no, but the sole available definition of "portable" says that it is
> >>>"portable" to assume that all the memory malloc can return is r
In message <9469.983047707@critter>, Poul-Henning Kamp writes:
>The guarantee is "If malloc returns NULL there is no memory you can use".
No, it's "if the memory is not available, malloc returns NULL".
>That doesn't mean that just because != NULL is returned that memory
>will in fact be availabl
In message <[EMAIL PROTECTED]>, Peter Seebach writes
:
>In message <9402.983047348@critter>, Poul-Henning Kamp writes:
>>>Well, no, but the sole available definition of "portable" says that it is
>>>"portable" to assume that all the memory malloc can return is really
>>>available.
>
>>No, this is
In message <9402.983047348@critter>, Poul-Henning Kamp writes:
>>Well, no, but the sole available definition of "portable" says that it is
>>"portable" to assume that all the memory malloc can return is really
>>available.
>No, this is not a guarantee.
Yes, it is. If the memory isn't available,
[EMAIL PROTECTED] (Peter Seebach) writes:
> In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
> >Malloc() does not overcommit - the kernel does. Malloc() doesn't know
> >and doesn't care.
> But it could still probably force the behavior.
Barring kernel changes, not easily, and only for
In message <[EMAIL PROTECTED]>, Peter Seebach writes
:
>In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
>>Malloc() does not overcommit - the kernel does. Malloc() doesn't know
>>and doesn't care.
>
>But it could still probably force the behavior.
>
>>None of these solutions are portabl
In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
>Malloc() does not overcommit - the kernel does. Malloc() doesn't know
>and doesn't care.
But it could still probably force the behavior.
>None of these solutions are portable, however;
Well, no, but the sole available definition of "p
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> if (sigsetjmp(env) == -1) {
Blah, this should be
if (sigsetjmp(env, 1) == -1) {
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[EMAIL PROTECTED] (Peter Seebach) writes:
> Is there any hope that, some day, a setting could be provided where a program
> could request that malloc *NOT* overcommit? There are programs which would
> rather know in advance, and clean up, than be killed abruptly.
Malloc() does not overcommit - t
In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
>This is all academic since FreeBSD does memory overcommit, so unless
>you run out of address space for your process before you run out of
>actual memory and/or swap (not likely, but quite possible) malloc()
>will never return NULL and yo
[EMAIL PROTECTED] (Peter Seebach) writes:
> In message <[EMAIL PROTECTED]>, Farooq Mela writes:
> > How do you guys feel about this?
> It is a mistake to believe that you "don't have to worry about running
> out of memory". You should always check, every time, and exit as gracefully
> as you can.
Farooq Mela <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Usually when I write programs, I have functions such as the following:
>
> void *
> xmalloc(size_t size)
> {
>
> }
>
> void *
> xrealloc(void *ptr, size_t size)
> {
>
> }
>
> And then I use these instead of malloc and realloc t
* Farooq Mela <[EMAIL PROTECTED]> [010223 00:22] wrote:
> Alfred Perlstein wrote:
> >
> > * Farooq Mela <[EMAIL PROTECTED]> [010222 23:52] wrote:
> > >
> > > This is not what I am arguing. I gave a simple example of an xmalloc
> > > function which does just print an error and exit. However, I've
Alfred Perlstein wrote:
>
> * Farooq Mela <[EMAIL PROTECTED]> [010222 23:52] wrote:
> >
> > This is not what I am arguing. I gave a simple example of an xmalloc
> > function which does just print an error and exit. However, I've written
> > many large applications using this sort of scheme where
* Farooq Mela <[EMAIL PROTECTED]> [010222 23:52] wrote:
>
> This is not what I am arguing. I gave a simple example of an xmalloc
> function which does just print an error and exit. However, I've written
> many large applications using this sort of scheme where when allocation
> fails, all sorts o
Peter Seebach wrote:
>
> In message <[EMAIL PROTECTED]>, Farooq Mela writes:
> >Of course I realize that allocating memory can fail. That is why I use
> >xmalloc and friends - so that I can avoid having to check for failure
> >each time I want to allocate memory.
>
> That's the problem. You sti
In message <[EMAIL PROTECTED]>, Farooq Mela writes:
>Of course I realize that allocating memory can fail. That is why I use
>xmalloc and friends - so that I can avoid having to check for failure
>each time I want to allocate memory.
That's the problem. You still *NEED* to check. You can't just
Peter Seebach wrote:
> It is a mistake to believe that you "don't have to worry about running
> out of memory". You should always check, every time, and exit as gracefully
> as you can.
>
> -s
Of course I realize that allocating memory can fail. That is why I use
xmalloc and friends - so that
In message <[EMAIL PROTECTED]>, Farooq Mela writes:
>How do you guys feel about this?
It is a mistake to believe that you "don't have to worry about running
out of memory". You should always check, every time, and exit as gracefully
as you can.
-s
To Unsubscribe: send mail to [EMAIL PROTECTED]
Hi,
Usually when I write programs, I have functions such as the following:
void *
xmalloc(size_t size)
{
void *p;
if ((p=malloc(size))==NULL) {
fprintf(stderr, "out of memory\n");
exit(1);
}
return(p);
}
void *
xrealloc(void *ptr,
90 matches
Mail list logo
