Re: Warnings about error_t in glibc on GNU/Hurd

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Mon, 23 Jul 2012 21:29:42 -0400, Barry deFreese <bdefreese@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).

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

See here:
<http://www.gnu.org/software/hurd/open_issues/glibc.html#index1h2>.

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

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

That's another option.  (Which obvious detail am I missing though: why
doesn't GCC warn in this case (see below) if it does warn for Âcase 0:Â
in switch?)

Another option is to cast the error_t to int in the switch statements
(but we typically want to avoid such casts).  There is no issue with user
programs doing Âswitch (errno)Â and including a Âcase 0:Â, because that
a) is not a valid thing to do as errno only is to be evaluated if it has
been set before (and that having been indicated by the failing function),
and b) errno at this level is not a error_t but a plain int.

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

    $ for v in {4..7}; do echo gcc-4.$v && echo 'typedef enum __error_t_codes { EFOO = 1 } error_t; int foo (error_t err) { if (err == 0) return 0; return 1; }' | gcc-4.$v -Wall -c -x c - -o /dev/null; done
    gcc-4.4
    gcc-4.5
    gcc-4.6
    gcc-4.7

    $ for v in {4..7}; do echo gcc-4.$v && echo 'typedef enum __error_t_codes { EFOO = 1 } error_t; int foo (error_t err) { switch (err) { case 0: return 0; default: break; } return 1; }' | gcc-4.$v -Wall -c -x c - -o /dev/null; done
    gcc-4.4
    gcc-4.5
    <stdin>: In function âfooâ:
    <stdin>:1:91: warning: case value â0â not in enumerated type âerror_tâ
    gcc-4.6
    <stdin>: In function âfooâ:
    <stdin>:1:91: warning: case value â0â not in enumerated type âerror_tâ [-Wswitch]
    gcc-4.7
    <stdin>: In function âfooâ:
    <stdin>:1:91: warning: case value â0â not in enumerated type âerror_tâ [-Wswitch]

    $ for v in {4..7}; do echo gcc-4.$v && echo 'typedef enum __error_t_codes { ESUCCESS = 0, EFOO = 1 } error_t; int foo (error_t err) { if (err == 0) return 0; return 1; }' | gcc-4.$v -Wall -c -x c - -o /dev/null; done
    gcc-4.4
    gcc-4.5
    gcc-4.6
    gcc-4.7

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


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature