Markus Hitter wrote:
Quite obviously, we have very different expectations on what
executables should do. I expect code to be as reliable as possible, to
be careful when aquiring resources and if a process would ever happen
to make my computer spontanuously reboot, I'd throw that binary as
Am 05.01.2008 um 03:47 schrieb Rob Landley:
You can disable overcommit and give the system an egregious amount
of swap
space, but then your pathological case is the system going into swap
thrashing la-la land and essentially freezing (advancing at 0.1% of
its
normal rate, if that, for
On Friday 04 January 2008, Markus Hitter wrote:
Am 03.01.2008 um 15:02 schrieb Paul Brook:
Having to check every return value is extremely tedious and (as
you've proved) easy to miss.
Checking every return value is a measure for programming reliable code.
Never failing is even more
Am 03.01.2008 um 15:02 schrieb Paul Brook:
Having to check every return value is extremely tedious and (as
you've proved)
easy to miss.
Checking every return value is a measure for programming reliable code.
If the allocation fails we don't have any viable alternatives, so
we may as
Paul Brook wrote:
What about a meaningful exit message?
Out of memory is a fairly comprehensive description of the problem.
In fact I'd say it's much more informative than random widget the user
doesn't know or care about failed to initialize.
If the user requested a target
On modern operating systems, allocations only return zero when you exhaust
virtual memory. Returning nonzero doesn't mean you have enough memory,
because it's given you a redundant copy on write mapping of the zero page
and will fault in physical pages when you write to 'em, which has _no_
On Friday 04 January 2008 19:07:58 Paul Brook wrote:
On modern operating systems, allocations only return zero when you
exhaust virtual memory. Returning nonzero doesn't mean you have enough
memory, because it's given you a redundant copy on write mapping of the
zero page and will fault
We currently don't check the return value in the init function where the
new timer is created but do check it wherever it is used which is backwards
and wasteful.
You would prefer that qemu just segfaults rather than die gracefully?
I think qemu should die before it returns from qemu_malloc.
s = (ptimer_state *)qemu_mallocz(sizeof(ptimer_state));
+ if (!s)
+ return NULL;
None of the callers bother to check the return value, And even if they did I
don't think there's any point trying to gracefully handle OOM. Just abort
and be done with it.
I suggest guaranteeing
Paul Brook wrote:
s = (ptimer_state *)qemu_mallocz(sizeof(ptimer_state));
+if (!s)
+return NULL;
None of the callers bother to check the return value, And even if they did I
don't think there's any point trying to gracefully handle OOM. Just abort
and be done with it.
10 matches
Mail list logo
