Re: Warnings about error_t in glibc on GNU/Hurd

[Barry deFreese <bdefreese at debian dot org>]

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