From owner-svn-src-all@freebsd.org Wed Jul 20 07:32:11 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D029B9C87A; Wed, 20 Jul 2016 07:32:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 3B97F17E2; Wed, 20 Jul 2016 07:32:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-149-109.carlnfd1.nsw.optusnet.com.au (c122-106-149-109.carlnfd1.nsw.optusnet.com.au [122.106.149.109]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 816BCD4A084; Wed, 20 Jul 2016 17:32:02 +1000 (AEST) Date: Wed, 20 Jul 2016 17:32:01 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh cc: Jan Beich , Ed Maste , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r303033 - head/share/man/man7 In-Reply-To: Message-ID: <20160720170316.T3729@besplex.bde.org> References: <201607191746.u6JHk9ov092270@repo.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=EfU1O6SC c=1 sm=1 tr=0 a=R/f3m204ZbWUO/0rwPSMPw==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=tITsiVaQAAAA:8 a=6I5d2MoRAAAA:8 a=ST0UujPXQ9mVs6hp854A:9 a=CjuIK1q_8ugA:10 a=Rrwg1Sb9G9BBOlP1exfM:22 a=IjZwj45LgO3ly-622nXo:22 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 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: Wed, 20 Jul 2016 07:32:11 -0000 On Tue, 19 Jul 2016, Warner Losh wrote: > On Tue, Jul 19, 2016 at 9:01 PM, Jan Beich wrote: >> Ed Maste writes: >> >>> +.Ss Predefined Macros >>> +The compiler provides a number of predefined macros. >>> +Some of these provide architecture-specific details and are explained below. >>> +Other macros, including those required by the language standard, are not >>> +included here. >> [...] >>> +cc -x c -Dm -E /dev/null >> >> Typo: -Dm vs. -dM >> >>> +.It Dv BYTE_ORDER Ta Either Dv BIG_ENDIAN or Dv LITTLE_ENDIAN . >> >> Are these really compiler macros? I think, defines them. These are non-compiler-predefined macros. They are namespace pollution in which is only there in the __BSD_VISIBLE case. > sys/endian.h defines them (and it implements that by including machine/endian.h > in part). > >> $ clang38 -x c -dM -E /dev/null | fgrep ENDIAN >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> #define __LITTLE_ENDIAN__ 1 >> #define __ORDER_BIG_ENDIAN__ 4321 >> #define __ORDER_LITTLE_ENDIAN__ 1234 >> #define __ORDER_PDP_ENDIAN__ 3412 These are the related compiler definitions in the implementation namespace. Their spelling is quite different and there are no consistency checks between values, but the ABI requires similar values. The values are as different as the spellings in some cases. __LITTLE_ENDIAN__ is 1, but FreeBSD's _LITTLE_ENDIAN is 1234. Actually, the semantics of these is very different too. FreeBSD's _LITTLE_ENDIAN corresponds to __ORDER_LITTLE_ENDIAN. >> $ gcc5 -x c -dM -E /dev/null | fgrep ENDIAN >> #define __ORDER_LITTLE_ENDIAN__ 1234 >> #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ >> #define __ORDER_PDP_ENDIAN__ 3412 >> #define __ORDER_BIG_ENDIAN__ 4321 >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ gcc apparently doesn't even have the confusing __LITTLE_ENDIAN__. > This is why they are defined in machine/endian.h. Compilers have been > somewhat inconsistent in the past. But they aren't defined in machine/endian.h. Compilers had no trace of them in the past. Even gcc-4.2 in the present /usr/src doesn't have them. The FreeBSD macros should be used since they have been portable in BSD for at last 25 years, with a better spelling which is unsuitable for standards because it is not ugly enough to not be already in use with possibly inconsistent semantics. glibc is different again. In an old version (2.6), it uses __BYTE_ORDER where FreeBSD uses _BYTE_ORDER and compilers use __BYTE_ORDER__. It also defines the FreeBSD pollution BYTE_ORDER in string/endian.h and uses this in dangerous places like netinet/icmp6.h, but in the standard netinet/in.h which doesn't allow this, it is more careful and uses __BYTE_ORDER. The man page might need to be more careful about this. BYTE_ORDER is not a compiler predefine or standard spelling and determing the applicable spelling is time-consuming. Bruce