[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
From: |
Eli Zaretskii |
Subject: |
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. |
Date: |
Fri, 27 Nov 2015 09:35:59 +0200 |
> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Thu, 26 Nov 2015 13:29:49 -0800
>
> Eli Zaretskii wrote:
> > it would be a maintenance burden to have to
> > analyze upon each such change whether emacs-module.c needs some
> > augmentation.
>
> While that's true in general, I think some exceptions are OK. E.g., it's OK
> if
> emacs-module.c assumes that ASIZE is a simple access function or macro that
> doesn't throw signals. If we actually changed ASIZE to throw signals,
> there's a
> boatload of other code we'd need to change as well, and changing
> emacs-module.c
> wouldn't add much more to the maintenance burden.
So what are the rules here, exactly? I'd like to write them down in
the commentary to emacs-module.c, so that any future changes there
will have lower probability of breaking things.
E.g., can make_number signal an error? What about make_float or
make_string? And what about accessors like XFLOAT_DATA or AREF?