Re: Warnings about error_t in glibc on GNU/Hurd

[Thomas Schwinge]

Hi!

On Tue, 24 Jul 2012 11:39:02 +0200, I wrote:
> On Mon, 23 Jul 2012 21:29:42 -0400, Barry deFreese <bdefreese@debian.org> 
> wrote:
> > How about ENOERR?? :)  Sorry, couldn't resist.
> 
> If going that route, I'd prefer ESUCCESS -- in spirit of Mach's
> KERN_SUCCESS, D_SUCCESS (devices), ERR_SUCCESS (from <mach/error.h>, of
> type mach_error_t, also known as err_none -- but neither of which is used
> anywhere).

(And MACH_MSG_SUCCESS (which used in a few places in glibc in »switch
((error_t) err)« statements) also already is #defined with code 0, but
not added into the error_t enum.)

> > BTW, Thomas has a listing of several of the errors/warnings listed here:

<http://www.gnu.org/software/hurd/open_issues/glibc.html#index2h2>.

> > On 7/23/2012 3:51 PM, Roland McGrath wrote:
> > > Grepping for 'case 0:' shows exactly 8 places where this warning
> > > should arise.  One of those is the __hurd_fail inline in hurd.h, so
> > > that one instance probably generates the warning in many
> > > compilations.
> 
> Correct.

> > > I'm not real sure about giving an E* name to 0, since E* names are
> > > for error codes, and 0 isn't one.  But OTOH for error_t 0 is
> > > certainly one of the expected values, so it makes sense to have an
> > > enum constant for it.  The question is what name to use, and then
> > > whether to actually use that name or just add it to suppress the
> > > warning while still using 0 in the code.

> > > Assuming the warning behavior is consistent with what I've seen, my
> > > inclination is not to change the code to use a symbolic name for
> > > this.  That's mostly because the obvious choices like ESUCCESS or
> > > EOK just seem wrong to me since the E* name space ought to be for
> > > actual error codes, and I can't think of a good name I'd actually
> > > want to be writing in the code.  So I'm inclined to pick some name
> > > that is not very friendly to use (i.e. long and verbose), perhaps
> > > even in the _* space, and add that to the error_t enum just for the
> > > purpose of suppressing these warnings and not expect people to use
> > > it in the code.
> 
> That could be done in sysdeps/mach/hurd/errnos.awk:BEGIN to avoid having
> to go through the manual.

I'd suggest to go with the simple ESUCCESS instead of spending some more
months ;-) thinking about a "more suitable" name.  Here is the patch I
tested to fix all these issues; OK to commit?

        * sysdeps/mach/hurd/errnos.awk (BEGIN): Emit ESUCCESS.
        * sysdeps/mach/hurd/bits/errno.h: Regenerate.

diff --git a/sysdeps/mach/hurd/bits/errno.h b/sysdeps/mach/hurd/bits/errno.h
index 3b6fe76..635cfb3 100644
--- a/sysdeps/mach/hurd/bits/errno.h
+++ b/sysdeps/mach/hurd/bits/errno.h
@@ -9,6 +9,9 @@
 
 enum __error_t_codes
 {
+       /* Avoid warning: case value '0' not in enumerated type 'error_t'.  */
+       ESUCCESS = 0,
+
 #undef EDOM
 #undef ERANGE
        EPERM           = _HURD_ERRNO (1),
diff --git a/sysdeps/mach/hurd/errnos.awk b/sysdeps/mach/hurd/errnos.awk
index 9748e6e..cfff09c 100644
--- a/sysdeps/mach/hurd/errnos.awk
+++ b/sysdeps/mach/hurd/errnos.awk
@@ -32,6 +32,9 @@ BEGIN {
     print "";
     print "#ifdef _ERRNO_H\n";
     print "enum __error_t_codes\n{";
+    print "\t/* Avoid warning: case value '0' not in enumerated type 
'error_t'.  */";
+    print "\tESUCCESS = 0,"
+    print "";
     errnoh = 0;
     maxerrno = 0;
     in_mach_errors = "";


Grüße,
 Thomas

pgpMvSZONvlHy.pgp
Description: PGP signature