Subject: bug#75755: feature/igc: Missing IGC_CHECK_RES?

From: Stefan Kangas <[email-masked]>
Date: Wed, 22 Jan 2025 13:52:07 -0800

Pip Cet <[email-masked]> writes:

> "Stefan Kangas" <[email-masked]> writes:
>
>> Gerd Möllmann <[email-masked]> writes:
>>
>>> Pip Cet <[email-masked]> writes:
>>>
>>>> "Pip Cet" <[email-masked]> writes:
>>>>
>>>> My preference would be to add this code before result_string:
>>>>
>>>> /* Define a named enumeration containing all cases that the integer type
>>>>    mps_res_t is known to cover.  */
>>>>
>>>> enum mps_res_enum
>>>> {
>>>>   _mps_RES_ENUM (RES_CASE, MPS_RES_)
>>>> };
>>>> #undef RES_CASE
>>>
>>> That would be nice, indeed.
>>
>> Can we rely on this or is it an internal API?
>
> It's an internal API.  The header has this to say:
>
>  * .naming.internal: Any identifier beginning with an underscore is for
>  * internal use within the interface and may change or be withdrawn without
>  * warning.
>
> I don't think that it's always horrible to rely on internal APIs,
> though.  Maybe we can put it inside "#ifdef _mps_RES_ENUM", with a
> comment explaining that if in some distant future there are compilation
> errors because _mps_RES_ENUM is defined differently, the #ifdef block
> can safely be omitted?

AFAICT, being non-exhaustive risks that people will get suboptimal
errors, and being exhaustive means that we can get optimal errors on
master sooner.

OTOH, the situation I'm concerned about is if someone is trying to build
an old Emacs tarball with the latest MPS.  If the internal identifier
disappears, or its interface changes, the build will be broken.  The MPS
developers warn that such a change could happen "without warning".

Are the benefits of using it large enough to be worth the risks?  I'm
currently leaning towards "no", but it's possible that I'm missing
something.