From owner-svn-src-all@FreeBSD.ORG Tue Apr 21 09:32:36 2015 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3CA03B6; Tue, 21 Apr 2015 09:32:36 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 85D221CF2; Tue, 21 Apr 2015 09:32:35 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 7023F4269AD; Tue, 21 Apr 2015 19:32:31 +1000 (AEST) Date: Tue, 21 Apr 2015 19:32:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David Chisnall cc: Bruce Evans , John Baldwin , Justin Hibbits , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r281721 - head/sys/sys In-Reply-To: <785A553E-317E-4C80-83A0-567C80697ED8@FreeBSD.org> Message-ID: <20150421184157.Y2048@besplex.bde.org> References: <201504190033.t3J0XMDX041769@svn.freebsd.org> <476583045.Qcb6O2DFtY@ralph.baldwin.cx> <20150421020808.D10623@besplex.bde.org> <785A553E-317E-4C80-83A0-567C80697ED8@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=dKqfxopb c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=FpqDrhUIJt8TsK9rtWoA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 09:32:37 -0000 On Tue, 21 Apr 2015, David Chisnall wrote: > On 20 Apr 2015, at 17:19, Bruce Evans 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 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 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