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

From: Pip Cet <[email-masked]>
Date: Wed, 22 Jan 2025 22:42:01 +0000

"Stefan Kangas" <[email-masked]> writes:

> 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,

The #ifdef block will simply not be evaluated, and the build will
continue to work.  It'll behave differently in this minor way, but
that's to be expected when a header changes.

> or its interface changes, the build will be broken.  The MPS

That is correct; I hope this is much less likely to happen, but if it
does, we're stuck with unbuildable old Emacs-new MPS combinations.

> 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.

I did not introduce the dependency; I moved it around and had some
preprocessor fun while doing so.  I think it's time to remove it now,
though, but that's not a strong opinion.  Please feel free to do what
you think is best on the branch.  If you have a hard time deciding,
there's always the option of keeping it behind a usually-deactivated
#ifdef, like the BYTE_CODE_SAFE code.

Pip