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

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefankangas <at> gmail.com>

Date: Wed, 22 Jan 2025 10:28:02 UTC

Severity: normal

Done: Pip Cet <pipcet <at> protonmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 75755 <at> debbugs.gnu.org, acorallo <at> gnu.org,
 eller.helmut <at> gmail.com, gerd <at> gnu.org
Subject: Re: bug#75755: feature/igc: Missing IGC_CHECK_RES?
Date: Thu, 23 Jan 2025 11:51:50 -0600
Pip Cet <pipcet <at> protonmail.com> writes:

> "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?

FWIW, I'd keep it simple here and just install this.  At the end of the
day, while suboptimal, it's also not the end of the world if a new error
returns the "unknown error" string.  We do get the numerical error code,
so we can always decipher it.

diff --git a/src/igc.c b/src/igc.c
index 57c13614f73..b02d29ca4da 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -252,18 +252,6 @@
 static enum igc_state igc_state = IGC_STATE_INITIAL;
 static void set_state (enum igc_state state);

-/* Define a named enumeration containing all cases that the integer type
-   mps_res_t is known to cover.  */
-
-#define RES_CASE(prefix, id, doc)                                            \
-  id,
-
-enum mps_res_enum
-{
-  _mps_RES_ENUM (RES_CASE, MPS_RES_)
-};
-#undef RES_CASE
-
 /* Convert an mps result code into a result string.  This shouldn't
    allocate memory because it's called when a fatal memory management
    error occurs. */
@@ -271,9 +259,7 @@ #define RES_CASE(prefix, id, doc)
                          \
 static const char *
 mps_res_to_string (mps_res_t res)
 {
-  /* mps_res_t is typedef'd to int, we want an enum so GCC warns about
-     new cases.  */
-  switch ((enum mps_res_enum) res)
+  switch (res)
     {
     case MPS_RES_OK:
       return "operation succeeded";




This bug report was last modified 163 days ago.

Previous Next


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