i think you're optimising for the corner case. do you expect every program
in /sys/src/cmd to want or need to recover from a malloc error or a sysfatal?
btw. why would you return an error for these cases:
lib9p/srv.c: sysfatal("no walk function, no file trees");
ibString/s_grow.c: sysfatal("s_grow of constant string");
libString/s_putc.c: sysfatal("can't s_putc a shared string");
libString/s_read.c: sysfatal("can't s_read a shared string");
libString/s_read_line.c: sysfatal("can't s_read_line a shared
string");
libString/s_terminate.c: sysfatal("can't s_terminate a shared
string");
[etc.]
what could you do about this one:
libthread/note.c: sysfatal("libthread: too many delayed notes");
- erik
On Fri Jun 9 19:51:55 CDT 2006, [EMAIL PROTECTED] wrote:
> On Fri, Jun 09, 2006 at 05:45:29PM -0700, Roman Shaposhnick said:
> > Now, don't get me wrong -- sometimes you have to make an extra effort
> > to at least pretend that it is solvable. Especially when you are in a
> > business of building commercial software. I can appreciate it. But lets
> > move our discussion to a practical level -- could you explain what
> > sort of "alternative" control flow you're after when something bad
> > happens inside the library. What kind of an ideal world solution
> > would you like to see as an application developer ?
>
> Umm, like returning an error? :)
