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