[9fans] making emalloc a library function

[9fans] making emalloc a library function

[Einar Karttunen]

Hello

Quite many programs define emalloc, which does the same thing. I was
thinking of ripping these out and replacing with a library.

I have two alternative routes. Either make libemalloc which contains
emalloc, estrdup and so on or add a flag which makes libc malloc behave
like emalloc. 

The first way would give programs freedom, but library code would still
use raw malloc instead of the emalloc. The second solution would be
harder for programs wishing to use both emalloc and malloc (of course
this would be still possible), but it would be more general... 
The changes would break no existing code in either case. 
Should I go forward with either idea?

- Einar Karttunen

Re: [9fans] making emalloc a library function

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

If its just a flag, some libraries will start to depend on the
behavior and noone will be able to write programs that use the
libraries and still can survive running out of memory.  I think
we should just bite the bullet and add e(malloc,realloc,mallocz)
to the library.

[-- Attachment #2: Type: message/rfc822, Size: 3023 bytes --]

From: Einar Karttunen <ekarttun@cs.helsinki.fi>
To: Plan9 ML <9fans@cse.psu.edu>
Subject: [9fans] making emalloc a library function
Date: Sun, 7 Mar 2004 13:32:09 +0200
Message-ID: <20040307113209.GA18849@melkki.cs.Helsinki.FI>

Hello

Quite many programs define emalloc, which does the same thing. I was
thinking of ripping these out and replacing with a library.

I have two alternative routes. Either make libemalloc which contains
emalloc, estrdup and so on or add a flag which makes libc malloc behave
like emalloc. 

The first way would give programs freedom, but library code would still
use raw malloc instead of the emalloc. The second solution would be
harder for programs wishing to use both emalloc and malloc (of course
this would be still possible), but it would be more general... 
The changes would break no existing code in either case. 
Should I go forward with either idea?

- Einar Karttunen

Re: [9fans] making emalloc a library function

[andrey mirtchovski]

deja vu...  anyone looking to add e* functions to a library should
read the 'same functions everywhere' thread started almost exactly
a year ago.  contains some good arguments against it.

andrey

Re: [9fans] making emalloc a library function

[andrey mirtchovski]

> 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

Re: [9fans] making emalloc a library function

[Rob Pike]

> deja vu...  anyone looking to add e* functions to a library should
> read the 'same functions everywhere' thread started almost exactly
> a year ago.  contains some good arguments against it.

right.  my main objection is that the specification of what to do in the
case of errors is so application-dependent that making a library for it
will either fail to capture many cases or encourage programs to fail
poorly.

plus, i mean really, how hard is emalloc to write?  the  part you'd
put in a library is trivial.  the part that matters is still up to you.

-rob

Re: [9fans] making emalloc a library function

[Einar Karttunen]

On 07.03 09:06, Rob Pike wrote:
> right.  my main objection is that the specification of what to do in the
> case of errors is so application-dependent that making a library for it
> will either fail to capture many cases or encourage programs to fail
> poorly.

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.

The functions lib9p seem to do this (at least close). Would it 
be possible to start from there? 
 
> plus, i mean really, how hard is emalloc to write?  the  part you'd
> put in a library is trivial.  the part that matters is still up to you.

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. Also if one writes a malloc wrapper which 
behaves unlike the emallocs naming it emalloc is quite confusing.

- Einar Karttunen

Re: [9fans] making emalloc a library function

[9nut]

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

Not if emalloc is in the application in every instance.

Re: [9fans] making emalloc a library function

[9nut]

> plus, i mean really, how hard is emalloc to write?  the  part you'd
> put in a library is trivial.  the part that matters is still up to you.

"I'm with you, captain" -- boyd

Re: [9fans] making emalloc a library function

[boyd, rounin]

> deja vu...

déjà ;)

Re: [9fans] making emalloc a library function

[boyd, rounin]

> right.  my main objection is that the specification of what to do in the
> case of errors is so application-dependent that making a library for it
> will either fail to capture many cases or encourage programs to fail
> poorly.

exactly, unless you add yet another two arguments (which i'd be
loathed to do):

   - function to call on failure
   - arg to function

but i'd guess that this would degenerate to:

    - exits
    - "ran out of memory"

so i'd be against it.

malloc failing is not always fatal.

Re: [9fans] making emalloc a library function

[Geoff Collyer]

> TPOP was the first to mention emalloc (not that it wasn't used before)

Actually emalloc was mentioned in publications at least as early as
1984, in The UNIX Programming Environment.

Re: [9fans] making emalloc a library function

[boyd, rounin]

> Actually emalloc was mentioned in publications at least as early as
> 1984, in The UNIX Programming Environment.

at basser we called it salloc(), back in 82.

Re: [9fans] making emalloc a library function

[Douglas A. Gwyn]

Einar Karttunen wrote:
> I have two alternative routes. Either make libemalloc which contains
> emalloc, estrdup and so on or add a flag which makes libc malloc behave
> like emalloc. 

It is a *very* bad idea to change the behavior of malloc().
Your program might link with some library that knows how to
recover when malloc() reports failure, and if you change
malloc() to act like emalloc() you will break that library.

There should be no problem adding emalloc() to the system C
library.

Re: [9fans] making emalloc a library function

[Douglas A. Gwyn]

boyd, rounin wrote:
>>Actually emalloc was mentioned in publications at least as early as
>>1984, in The UNIX Programming Environment.
> at basser we called it salloc(), back in 82.

And xmalloc() harks back to PWB, circa 1976.
My own malloc implementation supports throwing an
exception if you want to use it in a suitable
environment where that is the general scheme.