Date: Tue, 21 Apr 2015 19:32:30 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: David Chisnall <theraven@FreeBSD.org> Cc: Bruce Evans <brde@optusnet.com.au>, John Baldwin <jhb@FreeBSD.org>, Justin Hibbits <jhibbits@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r281721 - head/sys/sys Message-ID: <20150421184157.Y2048@besplex.bde.org> In-Reply-To: <785A553E-317E-4C80-83A0-567C80697ED8@FreeBSD.org> References: <201504190033.t3J0XMDX041769@svn.freebsd.org> <476583045.Qcb6O2DFtY@ralph.baldwin.cx> <20150421020808.D10623@besplex.bde.org> <785A553E-317E-4C80-83A0-567C80697ED8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Apr 2015, David Chisnall wrote:
> On 20 Apr 2015, at 17:19, Bruce Evans <brde@optusnet.com.au> wrote:
>>
>> Enums should never be used in ABIs, since their size can be anything
>> large enough.
>
> The rules for the size of enums also differ between C and C++, though clang (and, I think, gcc) support an attribute for specifying the enum type.
>
>> They also cause namespace problems. The whole enum declaration must
>> be exposed in any header that uses an enum type.
>
> Both C and C++ permit forward declarations of enums for use in function prototypes and so on, e.g.:
>
> enum foo;
> void
> bar(enum foo);
No, they cannot do this since the size may depend on the internals of the
enum:
TendDRA-5.0.0:
"z.c", line 1: Error:
[ISO C90 6.5.2.3]: Can't declare the enumeration 'enum foo'.
gcc-4.2.1 -std=c99 -pedantic:
z.c:1: warning: ISO C forbids forward references to 'enum' types
z.c:3: warning: ISO C forbids forward references to 'enum' types
clang-current -std==c99 -pedantic
z.c:1:6: warning: ISO C forbids forward references to 'enum' types [-Wpedantic]
g++-4.2.1:
z.cc:1: error: use of enum `foo' without previous declaration
clang++-current:
z.cc:1:6: error: ISO C++ forbids forward references to 'enum' types
It takes -pedantic to turn gcc-4.2.1 and clang-current into something
resembling C99 compilers, but in gcc++-4.2.1 and clang++-current
nothing is required and error is actually an error.
gcc and clang are still far behind TenDRA in the quality of their
diagnostics.
I thought that forward declarations of enums were allowed too, until
recently when their brokenness turned up in kernel builds. syscallsubr.h
is broken, since it uses `enum idtype' without declaring it, except
bogusly as a forward declaration as above. Only kern_wait6() and
kern_procctl() use this enum.
(syscallsubr.h also uses the older mistake `enum uio_seg', but it
has the namespace pollution of including <sys/uio.h> to get this
instead of being broken by this.
`enum uio seg' is under __BSD_VISIBLE, but it seems to be bogus
to export it to userland since it is only useful in the kernel.
struct uio is kernel-only.
wait6(2) has somewhat different design errors. It spells
`enum idtype' as idtype_t and also uses id_t. `enum idtype' is
declared with wait6() in <sys/wait.h> where it is not so polluting,
but still needs anti-pollution ifdefs since only idtype_t is
standard.)
The bug in syscallsubr.h was detected as a side effect when I enabled
-pedantic to check for other errors.
enums are not used much in the kernel or syscalls, and they seem to
mostly have complete declarations. The pollution problem would be
larger if there were more of them.
POSIX has excessive typedefs, but almost no enums, at least in old
versions. In a 2001 draft, it has just 4 lines out of 209786 containing
`enum', and a a few more containing `enumeration type'. Its only enum
types are:
/* For the bsearch family: */
enum { FIND, ENTER } ACTION;
enum { preorder, postorder, endorder, leaf } VISIT;
/* For wait6(): */
The type idtype_t shall be defined as an enumeration type whose
possible values shall include ...
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150421184157.Y2048>