GNU bug report logs - #75755
feature/igc: Missing IGC_CHECK_RES?

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: gerd <at> gnu.org, Helmut Eller <eller.helmut <at> gmail.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, 75755 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>
Subject: bug#75755: feature/igc: Missing IGC_CHECK_RES?
Date: Wed, 22 Jan 2025 22:42:01 +0000

"Stefan Kangas" <stefankangas <at> gmail.com> writes:

> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> "Stefan Kangas" <stefankangas <at> gmail.com> writes:
>>
>>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>>
>>>> Pip Cet <pipcet <at> protonmail.com> writes:
>>>>
>>>>> "Pip Cet" <pipcet <at> protonmail.com> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.