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

Previous Next

Full log

Message #32 received at 75755 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: pipcet <at> protonmail.com, eller.helmut <at> gmail.com, gerd <at> gnu.org,
 gerd.moellmann <at> gmail.com, 75755 <at> debbugs.gnu.org, acorallo <at> gnu.org
Subject: Re: bug#75755: feature/igc: Missing IGC_CHECK_RES?
Date: Thu, 23 Jan 2025 08:47:15 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Wed, 22 Jan 2025 13:52:07 -0800
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 
> 	75755 <at> debbugs.gnu.org, gerd <at> gnu.org, Helmut Eller <eller.helmut <at> gmail.com>, 
> 	Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>
> 
> 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, 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.

IMO, the single use of this macro is not worth of the complications
due to relying on an internal enumeration macro.  The single function
which uses this is a testing tool, which on top of that warns in its
doc string not to use it.  Introducing significant complexity and
breakage potential into Emacs due to this is IMO a tail wagging the
dog.

So I suggest that we define our own enumeration.  We could copy some
information from the MPS headers if needed (or not: I'm not sure we
should be wedded to their strings in this case).  Yes, that would mean
if they add or remove enumeration values, we will have some
maintenance work on our hands, but it doesn't seem a significant
problem for an internal function that almost no one should be using.

Previous Next

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