Re: xmalloc string functions

Yevgen Muntyan <muntyan@xxxxxxxxxxxxxxxxxxx> wrote:
<snip>
This is very very wrong. A typical GUI application does not do a
switch like

switch (problem_to_handle)
{
...
}

to which you could add

case ALLOC_FAILED:

It's usually different, you got the main loop which
got to spin, you got those controls you got to draw,
and you got those callbacks which actually do the
job. And the callbacks do one thing at a time, they
do not handle dozens of exceptional conditions at once,
they do not handle exceptional conditions at all
in fact.

Is that why applications crash when, using a file dialog box, I attempt to
save a file into a directory I don't have write permission to?

To my mind, there's no difference in effort required to handle a NULL return
from fopen(), than a NULL return from malloc(). Maybe more typing. This is
just a resource acquisition issue, and even if you had infinite memory it's
a pattern you still have to deal with.

As to main loops, I'm very familiar with these. I write event based async-io
network software, using an event dispatcher exactly like a GUI application
might. I create and use more callback interfaces than I probably should.
When I accept a connection, I might--though, try not to--do dozens of
allocations. I try to write my code so any allocation failure is handled
gracefully. I don't need a gigantic switch statement, or special language
constructs. One designs the code to deal with such a circumstances as a
matter of course. You minimize dependencies, isolate access to shared data,
postpone commiting to a particular state wrt to that context until you've
acquired a minimal set of resources, etc. Any non-trivial application
usually has multiple contexts within which such intermediate failures can be
contained, with practical benefit.

Granted, I've not done much work with X11 applications, or GUI applications
in general. But, I fail to understand how a caveat wrt to X11
justifies--absent other reasons--exiting when a string cannot be allocated.

And yet out of all of
them people will argue memory allocation alone can be completely ignored,
simply because it's too burdensome.

<snip>
Of course I am talking about "small" allocations here, not
about stuff like allocating memory to load an image file (for
those g_malloc() is simply not used).

There's absolutely no qualitative difference between small and large
allocations without reference to other circumstances (number of allocations,
etc). If I have 4GB of memory, what does it matter that a 10MB allocation is
checked but not a 12B allocation? When the application approaches the limit
its not likely that one will be more susceptible to failure than the other.
The choice is then arbitrary and almost absurd. Better, for consistency, to
not bother at all.

.

Relevant Pages

  • Re: Throwing bad_alloc when calling new on large class
    ... physical memory regardless of the /3G switch. ... to why the allocation of the class is failing. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: stack overflow
    ... complier options and if for production better switch to heap based ... memory allocation... ...
    (comp.lang.cpp)
  • Re: How to release heap memory that is marked as free
    ... As I said, fragmentation is a very serious problem, and one of the most serious problems ... my allocator was accused of using massive amounts of memory. ... I'm going to have to re-think the memory allocation that I'm ... process's 'working set'. ...
    (microsoft.public.vc.mfc)
  • Re: [PATCH 00/28] Swap over NFS -v16
    ... memory they can consume. ... So we need the extra (skb) ... included in the reserve? ... if the allocation had to dip into emergency reserves, ...
    (Linux-Kernel)
  • Re: Memory leak with CAsyncSocket::Create
    ... read my essay on how storage allocators work. ... Create method is consuming system memory that is not released back to ... The memory consumption is either shown as "Mem Usage" on the Task ... many levels of allocation going ...
    (microsoft.public.vc.mfc)