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 far
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 _hour
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
> 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 11:29:27 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.
There's an old t
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 "doesn't know or care about> failed to initialize".
If the user requested a target parameter that is beyond the
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 r
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 well
> 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_mal
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.
> 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 guaranteei
diff -p -u -r1.5 ptimer.c
--- hw/ptimer.c 17 Nov 2007 17:14:47 - 1.5
+++ hw/ptimer.c 3 Jan 2008 02:27:18 -
@@ -185,6 +185,8 @@ ptimer_state *ptimer_init(QEMUBH *bh)
ptimer_state *s;
s = (ptimer_state *)qemu_mallocz(sizeof(ptimer_state));
+if (!s)
+return NULL;
12 matches
Mail list logo
