This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Warnings about error_t in glibc on GNU/Hurd
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>, GNU Hurd Bug Mailing List <bug-hurd at gnu dot org>, <bdefreese at debian dot org>
- Date: Wed, 29 May 2013 15:53:24 -0700 (PDT)
- Subject: Re: Warnings about error_t in glibc on GNU/Hurd
- References: <500DA432 dot 40803 at debian dot org> <20120723195143 dot 7F8142C0B9 at topped-with-meat dot com> <500DFA86 dot 2060406 at debian dot org> <878ve9birt dot fsf at kepler dot schwinge dot homeip dot net> <87bo7uktpy dot fsf at kepler dot schwinge dot homeip dot net>
> I'd suggest to go with the simple ESUCCESS instead of spending some more
> months ;-) thinking about a "more suitable" name.
That is indisputably reasonable, but I did just find myself spending a few
minutes thinking about what name would be more suitable. ;-)
> + /* Avoid warning: case value '0' not in enumerated type 'error_t'. */
> + ESUCCESS = 0,
I don't think this is the right comment. If anybody reads this comment at
all, that doesn't tell them much. Perhaps something like:
/* The value zero always means success and it is perfectly fine for
code to use 0 explicitly (or implicitly, e.g. via Boolean coercion).
Having an enum entry for zero both makes the debugger print the name
for error_t-typed zero values, and prevents the compiler from issuing
warnings about 'case 0:' in a switch on an error_t-typed value. */