Re: Jitter macros that can abort

[Luca Saiu]

Hello José.

On 2022-01-01 at 23:41 +0100, Jose E. Marchesi wrote:

> There are several program-assembling related macros generated by
> Jitter that will abort under some circumstances.

The idea for a related feature came up, I think, in a discussion with
Mohammad: the idea would be to allow the user to override
malloc/free/realloc as used in a VM runtime, and use her own functions
instead.
(By the way, I have been neglecting Mohammad's message for a very long
time.  I am sorry Mohammad.  I will get to your messages.)

It would be nice to be able to use the same feature to allow a user
replacement for abort.  I guess it can be done at least in the case of
the functions you are citing.

They now return void, but I could change them to return a status code.
However, by default, unless the user overrides abort, the status code
would not be used and you would obtain the current semantics.  For the
time being assume that this status code is Boolean; it is not difficult
to refine it later in a backward-compatible way if you accept this idea.

Would this solution be acceptable to you?  I am willing to make the
change if the answer is yes.

Independently from the idea above, an aside:

> This is no good for a library like libpoke.

I understand your point of view here, but I am not convinced that
following this philosophy everywhere is the right thing.  The control
flow of a program checking for every possible out-of-memory error would
be complicated to follow, while buying you very little.  I suspect that
you will have a very high number of calls replaced by a pattern such as:

  if (pvm_routine_append_instruction_name (r, "drop") != pvm_status_ok)
    goto error;

with an “error” label at the end of each libpoke function.

Luckily these API functions currently return void and are not called
inside nontrivial expressions, because otherwise in standard C you would
have to rewrite such expressions.

I think that you can always prevent errors different from out-of-memory,
unless there are bugs in libpoke and unless you expose the PVM details
to library users -- which seems incompatible with your ideas about
modularity.
The only problem that you cannot handle statically is runtime resource
exhaustion, which here means memory.

I know that many libraries avoid aborting on out-of-memory errors.  But
do people actually *use* libraries this way?

Regards,

-- 
Luca Saiu
* My personal web site:  http://ageinghacker.net
* GNU Jitter:            https://www.gnu.org/software/jitter
* GNU epsilon:           https://www.gnu.org/software/epsilon

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

signature.asc
Description: PGP signature