Hi! On Tue, 24 Jul 2012 11:39:02 +0200, I wrote: > On Mon, 23 Jul 2012 21:29:42 -0400, Barry deFreese <bdefre...@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
pgpI4JPfZKBXY.pgp
Description: PGP signature
