Date: Fri, 16 Nov 2012 22:32:37 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, mdf@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r243134 - head/sys/sys Message-ID: <20121116203237.GO73505@kib.kiev.ua> In-Reply-To: <20121117040901.I3439@besplex.bde.org> References: <201211160625.qAG6PLd2032062@svn.freebsd.org> <CAMBSHm_xwP5S8ERXYL%2Bsw%2BBAfgTAss9i0EGoX5%2B1Hy40PhfXbg@mail.gmail.com> <20121116160539.GN73505@kib.kiev.ua> <20121117040901.I3439@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--zqRs+0AMW4nH7Axv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 17, 2012 at 04:24:06AM +1100, Bruce Evans wrote: > On Fri, 16 Nov 2012, Konstantin Belousov wrote: >=20 > > On Fri, Nov 16, 2012 at 08:02:39AM -0800, mdf@FreeBSD.org wrote: > >> On Thu, Nov 15, 2012 at 10:25 PM, Konstantin Belousov <kib@freebsd.org= > wrote: > >>> Author: kib > >>> Date: Fri Nov 16 06:25:20 2012 > >>> New Revision: 243134 > >>> URL: http://svnweb.freebsd.org/changeset/base/243134 > >>> > >>> Log: > >>> Alphabetically reorder the forward-declarations of the structures. > >>> Add the declaration for enum idtype, to be used later. > >> > >> Forward declarations of enums isn't an ISO C feature, but a gcc > >> extension. While the kernel uses many gcc extensions, it hides most > >> under a #define so unsupported compilers can continue along. This > >> unsupported feature can't be hidden. >=20 > Ugh. We discussed the unportability of enums in APIs when cleaning this > up. kib said that the size of an enum type is an ABI standard for i386 > and amd64. I don't quite agree for i386, and we didn't discuss other > arches. The size of an enum type must be fixed for the gcc extension > to be possible. In my copy of the SVID rev 4, document abi386, it is stated absolutely clear that Integral enum types are represented as the signed word with sizeof 4 and alignment 4. This is in Figure 3-1 Scalar Types, page 28. For amd64, in the ABI document 0.99.6, enums are again specified in the figure 3.1 as having signed fourbyte representation with the alighnment 4. Now, there is a footnote stating "C++ and some implementations of C permit enums larger than an int. The underlying type is bumped to an unsigned int, long int or unsigned long int, in that order. " But I think that the complain is not about the ABI, but regarding the use of the extension. I see three routes forward: - Keep the things as is. The only downside is the use of the extension which is supported by both gcc and clang. - Change idtype_t to int and use #defines to introduce P_XXX constants. This is not easy since Solaris contrib code uses enum, and enum was selected to not introduce unneeded incompatibility, at least for the kernel code. - Include sys/wait.h from sys/syscallsubr.h. A modification is to put idtype_h into a private header and include the header from syscallsubr.h and wait.h. My preference is to keep the things as is, but I am open for discussion. >=20 > gcc -std=3Dc99 -pedantic generates a warning for forward enum declaration. > Long ago, I routinely tested with -pedantic and committed fixes for all > the things that it found if they were not too hard to fix. >=20 > >> Does the forward declaration prevent another warning? > > > > It allows to prevent the namespace pollution from sys/wait.h idtype_t, = needed > > due to the kern_wait6() declaration. >=20 > syscallsubr.h and especially sysproto.h have lots of other namespace > pollution. My version of sysproto.h reduces the pollution to just > <sys/_sigset.h> using 6 #define hacks and 1 clean #include change to > reduce 5 polluting headers and 1 non-polluting one to 1 different > non-polluting one. The #define hacks can't work for enums. >=20 > When I worked on reducing the pollution in sysproto.h in its automatic > generation, I got it down to <sys/signal.h> and not much more. > <sys/_sigset.h> because available later, but -current still has the > full pollution of <sys/signal.h> and much more. Non-auto-generated > headers like syscallsubr.h are easier to clean. >=20 > Bruce --zqRs+0AMW4nH7Axv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCmouQACgkQC3+MBN1Mb4iexgCfcVUVFgE8+PXap+QXiNJR/vz8 eecAnRvbRnVvWin9puq8/3zdE1qkqR3t =nn5D -----END PGP SIGNATURE----- --zqRs+0AMW4nH7Axv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121116203237.GO73505>