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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: gerd <at> gnu.org, eller.helmut <at> gmail.com, gerd.moellmann <at> gmail.com, 75755 <at> debbugs.gnu.org, stefankangas <at> gmail.com, acorallo <at> gnu.org
Subject: bug#75755: feature/igc: Missing IGC_CHECK_RES?
Date: Thu, 23 Jan 2025 20:27:00 +0200

> Date: Thu, 23 Jan 2025 17:53:01 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: stefankangas <at> gmail.com, gerd.moellmann <at> gmail.com, 75755 <at> debbugs.gnu.org, gerd <at> gnu.org, eller.helmut <at> gmail.com, acorallo <at> gnu.org
> 
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> 
> >> Date: Thu, 23 Jan 2025 17:17:54 +0000
> >> From: Pip Cet <pipcet <at> protonmail.com>
> >> Cc: stefankangas <at> gmail.com, gerd.moellmann <at> gmail.com, 75755 <at> debbugs.gnu.org, gerd <at> gnu.org, eller.helmut <at> gmail.com, acorallo <at> gnu.org
> >>
> >> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> >>
> >> >> Date: Thu, 23 Jan 2025 14:34:56 +0000
> >> >> From: Pip Cet <pipcet <at> protonmail.com>
> >> >> Cc: Stefan Kangas <stefankangas <at> gmail.com>, gerd.moellmann <at> gmail.com, 75755 <at> debbugs.gnu.org, gerd <at> gnu.org, eller.helmut <at> gmail.com, acorallo <at> gnu.org
> >> >>
> >> >> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> >> >>
> >> >> > 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.
> >> >>
> >> >> I agree with this paragraph; it's not worth it, let's drop the code.
> >> >>
> >> >> > So I suggest that we define our own enumeration.  We could copy some
> >> >>
> >> >> Why?
> >> >
> >> > Because it's easy, and will still give us human-readable error
> >> > messages.
> >>
> >> How does defining an enum give us that?  Did you mean "our own switch
> >> statement"?  If so, what's wrong with the one on the current branch?
> >
> > We are talking past each other.  I meant the readable text that comes
> > with each enum value:
> >
> >   #define _mps_RES_ENUM(R, X) \
> >     R(X, OK,            "success (always zero)") \
> >     R(X, FAIL,          "unspecified failure") \
> >     R(X, RESOURCE,      "unable to obtain resources") \
> >     R(X, MEMORY,        "unable to obtain memory") \
> >     R(X, LIMIT,         "limitation reached") \
> >     R(X, UNIMPL,        "unimplemented facility") \
> >     R(X, IO,            "system I/O error") \
> >     R(X, COMMIT_LIMIT,  "arena commit limit exceeded") \
> >     R(X, PARAM,         "illegal user parameter value")
> >
> > which mps_res_to_string uses to produce a string for each value of
> > mps_res_t.
> >
> > IOW, I was not talking about defining an enum, I was talking about
> > defining a text string for each value of enum.
> 
> So what are you suggesting be changed?  We do that with a switch
> statement, in mps_res_to_string.  Are you proposing to do it another
> way?

I'm proposing to define, in igc.c, a set of strings, one each for
every value of the enumeration.  And then to use that in
mps_res_to_string to produce a human-readable error message describing
each mps_res_t value.

Previous Next

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