How about ENOERR?? :) Sorry, couldn't resist.
BTW, Thomas has a listing of several of the errors/warnings listed here:
http://www.gnu.org/software/hurd/open_issues/glibc.html#index1h1
I'm certainly fine with just adding a value for 0.
Thanks for taking the time to reply.
Barry
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.
Most of these are switches with only a few cases where it would be
easy to just change them to use 'if' instead of 'switch' without
complicating the code. Doing that would just avoid the question.
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.
I tried GCC 4.4, and it doesn't give this warning when you use an
integer literal as long as the enum has some name for that integer
value. If other GCC versions do warn for 'case 0:' when some item
'foo = 0' is in the enum, someone please tell me.
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.
Thanks,
Roland
