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.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,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 23966 invoked from network); 26 Jan 2021 21:35:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Jan 2021 21:35:14 -0000 Received: (qmail 5654 invoked by uid 550); 26 Jan 2021 21:35:11 -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 29881 invoked from network); 26 Jan 2021 21:29:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ycaU4Y6zH1PiX3ZP5g8V4jyX9FxDaqM4bFO8bBRcSDM=; b=uFaVzNKWNXKL/61bh973CsegMsFEvsN8c2LTSSJz2bd4/VfDP8oax5VWECGQm7JrAr GhAXHosTvM1Jmrd95ptpiKhes1bG5HUUzaV1h18M4JJlL5gb3VMzC13KeG/o+3CvgzGE xbD82gZOZJFBHmIMc2c06Ix2fJwxwupYvZF3iF4/2WJKHwbaBt2y6t2ZjnXPXgUp/ABI Ufwvr8QO7sLfd36KFs2k1BaMjlh/5M1Clq0EgQrzQXFbNnwtWLyWbH2PcVMlw+oq+/RI Ctj3EP9E0UvqhHxkbipypTpSND6z09o2RYS1z7ER1QXvBzNKY07coEw0Lnib5fEuddro bxvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ycaU4Y6zH1PiX3ZP5g8V4jyX9FxDaqM4bFO8bBRcSDM=; b=MspmN8yFqUM49WBtdbg/bB6IfaoiKzkkV5XRDlWsaGUYcHGepa+f+/FT6bvK6ARKC2 Y8MfEUUaSolk75N3KTl4WzwDuLeWY1fJp2fYuQ64VXOREfxEadUbfQkqbmFL4hJQV+k5 QCgua2Ze+lSNYFvpjDVFuj2/9els38xRJPviEOn9h8Uj1xiJHt3ltWswHYWFk75E52jR myE2CpO6adwnmD3cm4GdYgPPmBOd7kb9NlifVfvhxX7oKVgZpTBHg0pGIAMk+U9L5mER 4JX2rqhGLn0fTCxuljCUCMqGjynw+olaM69GSEFdvEYb3wIpvP/PMVUgP8n2q/mm/ZzP IS6w== X-Gm-Message-State: AOAM531fZTWi0Cw2hY5Ct+RYtU+NS77Gi7oJTwsU9aivZ0YfB/nkdjd2 2eAVfxIwDsqccrrv/PgCAO4T9hpIsY8G+JAXFlk= X-Google-Smtp-Source: ABdhPJxBjKzCX4TSrt26Api/dIQx9oBmtoxjE3DinUEK8Gen8zWPmouAv8Dt8fbeUFDZujjnIJz4BLf9Qm/ORBmZfDo= X-Received: by 2002:a05:6e02:589:: with SMTP id c9mr6060606ils.70.1611696557065; Tue, 26 Jan 2021 13:29:17 -0800 (PST) MIME-Version: 1.0 References: <20210126172330.GB23432@brightrain.aerifal.cx> In-Reply-To: <20210126172330.GB23432@brightrain.aerifal.cx> From: Andrey Melnikov Date: Wed, 27 Jan 2021 00:29:05 +0300 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [musl] Re: move __BYTE_ORDER definition to alltypes.h =D0=B2=D1=82, 26 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3. =D0=B2 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? > 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: #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 =3D *(const u32 *)addr; #else u16 a =3D *(const u16 *)addr; #endif #ifdef __BIG_ENDIAN return 0x01 & (a >> ((sizeof(a) * 8) - 8)); #else return 0x01 & a; #endif1234 } And now, we have defined __LITTLE_ENDIAN 1234 (from kernel headers), __BIG_ENDIAN 4321 (from stdarg header) - and code for BIG endian compiled for LITTLE endian machide. Doh. Please, return (BIG|LITTLE|PDP)_ENDIAN defines back to .