[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Warnings about error_t in glibc on GNU/Hurd

From: Barry deFreese
Subject: Re: Warnings about error_t in glibc on GNU/Hurd
Date: Mon, 23 Jul 2012 21:29:42 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0

How about ENOERR?? :)  Sorry, couldn't resist.

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

I'm certainly fine with just adding a value for 0.

Thanks for taking the time to reply.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]