Re: [9fans] making emalloc a library function

[andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>]

> Well it seems that many programs in the source tree want the same
> behaviour as it is. And no-one would be forced to use the library.

Isn't that the reverse of 'whoever wants it, could write it in their
own code'?  Less than 50% of all Plan 9 programs use emalloc so there
isn't a majority rule you can apply.

> 
> The functions lib9p seem to do this (at least close). Would it 
> be possible to start from there? 
> 

The exceptions that prove the rule?  See how they aren't called
'emalloc' :)

Have you considered at the problem from all sides?  What are your
suggested implementations for eallocimage() and egetwindow()?

> So why are part of the emalloc implementations missing e.g.
> setmalloctag? Of course it is quite trivial to write, but in my
> opinion having dozens of definitions for the same function is
> not exactly sane. 

TPOP was the first to mention emalloc (not that it wasn't used
before), its authors were wise not to suggest default behavior.

> Also if one writes a malloc wrapper which 
> behaves unlike the emallocs naming it emalloc is quite confusing.

Again, you assume emalloc has a well defined behaviour.  It doesn't.
The fact that everybody uses it the same way means that they haven't
really thought out how their programs should behave after malloc has
returned an error.  Would you be happy if fossil called the library
emalloc and sysfatal()-ed after some user process has allocated too
much memory "just for fun"?  What should fossil do, define
eemalloc()?

andrey