From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24628 invoked from network); 26 Jan 2021 21:40:54 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Jan 2021 21:40:54 -0000 Received: (qmail 14287 invoked by uid 550); 26 Jan 2021 21:40:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14249 invoked from network); 26 Jan 2021 21:40:45 -0000 Date: Tue, 26 Jan 2021 16:40:33 -0500 From: Rich Felker To: Andrey Melnikov Cc: musl@lists.openwall.com Message-ID: <20210126214032.GF23432@brightrain.aerifal.cx> References: <20210126172330.GB23432@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: move __BYTE_ORDER definition to alltypes.h On Wed, Jan 27, 2021 at 12:29:05AM +0300, Andrey Melnikov wrote: > вт, 26 янв. 2021 г. в 20:23, Rich Felker : > > > > On Tue, Jan 26, 2021 at 02:55:09PM +0300, Andrey Melnikov wrote: > > > Hi. > > > > > > Your commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea leads to > > > miscompile programs which rely on one of defines __LITTLE_ENDIAN or > > > __BIG_ENDIAN. > > > Now, both unconditionally defined when included stdarg.h and programs > > > which define __(BIG|LITTE)_ENDIAN itself - miscompiled. linux kernel > > > for example - it internally uses #if defined __BIG_ENDIAN and defines > > > it only for BIGENDAIN arches. > > > > > > Any ideas? > > > > The conditionally-defined macros that on some archs tell you the > > endianness are __BIG_ENDIAN__ and __LITTLE_ENDIAN__ (note the final > > Yes, defined by compiller. > > > __) or other arch-specific macros. __BIG_ENDIAN and __LITTLE_ENDIAN > > (without the final __) have always been the possible values for > > __BYTE_ORDER from endian.h. > > >From - its correct headers for this, not from . > is for va_* macros. > > > In any case, all of these are in the > > reserved namespace and should not be defined by applications or > > inspected in any way other than a manner documented by the > > implementation. > > Where is it reserved? 7.1.3 Reserved identifiers "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." > > How did this come up with the Linux kernel? AFAIK it uses -nostdinc > > and should not see the libc headers at all. But if that #ifdef is > > present in Linux it's probably a bug since it's contrary to all > > historical use of __BIG_ENDIAN... > > Easy. Build an out-of-tree module that includes which > is include which is define all variant _ENDIAN macros, > later it include which is include > in my case, > in (read > uapi/linux/byteorder/little_endian.h) we have defines: This also requires -nostdinc. The libc headers are not suitable for compiling kernel code. But in this case they should not be breaking anything. > #ifndef __LITTLE_ENDIAN > #define __LITTLE_ENDIAN 1234 > #endif > #ifndef __LITTLE_ENDIAN_BITFIELD > #define __LITTLE_ENDIAN_BITFIELD > #endif > > and later, include in module for > is_multicast_ether_addr() function: > > static inline bool is_multicast_ether_addr(const u8 *addr) > { > #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) > u32 a = *(const u32 *)addr; > #else > u16 a = *(const u16 *)addr; > #endif > #ifdef __BIG_ENDIAN > return 0x01 & (a >> ((sizeof(a) * 8) - 8)); > #else > return 0x01 & a; > #endif1234 > } This code is just wrong. It should be #if __BYTE_ORDER == __BIG_ENDIAN or #ifdef __BIG_ENDIAN__. Not #ifdef __BIG_ENDIAN. Where did the code come from? Whoever wrote it misunderstood the meanings of these macros. Even within the kernel they're not intended to be used this way. Rich