linux-kernel - Re: [PATCH] x86: Avoid undefined behavior in macro expansion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160319021533.GT17997@ZenIV.linux.org.uk>
Date:	Sat, 19 Mar 2016 02:15:33 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Vinicius Tinti <viniciustinti@...il.com>
Cc:	herbert@...dor.apana.org.au, davem@...emloft.net,
	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Avoid undefined behavior in macro expansion

On Wed, Mar 16, 2016 at 11:48:49PM -0300, Vinicius Tinti wrote:
> C11 standard (at 6.10.3.3) says that ## operator (paste) has undefined
> behavior when one of the result operands is not a valid preprocessing
> token.
> 
> Therefore the macro expansion may depend on compiler implementation
> which may or no preserve the leading white space.
> 
> Moreover other places in kernel use CONCAT(a,b) instead of CONCAT(a, b).
> Changing favors concise usage.

Huh?

> -#define	XMM(i)		CONCAT(%xmm, i)
> +#define	XMM(i)		CONCAT(%xmm,i)

What are you talking about?  Undefined behaviour is when the result of
concatenation of adjacent tokens is not a valid preprocessor token.
It says nothing about the either argument being a single token.

In this case after the substitution of e.g. XMM(42) we get 3 tokens:
Punctuator[%] Identifier[xmm] Pp-number[42]
with ## instructing us to replace the last two with preprocessor token that
would be represented as concatenation of their representations.  Which is
to say, concatenation of xmm and 42, i.e. xmm42.  Which *is* a
representation of a valid preprocessor token - namely, Identifier[xmm42].
No undefined behaviour at all.  And yes, you get two preprocessor tokens
in the expansion - % and xmm42.  Preprocessor works in terms of tokens,
not strings...

If you know of any compiler where these two variants would produce different
expansions of XMM(<sequence of digits>), please report it to maintainers of
the compiler in question; it's a bug, plain and simple.  And no, there's
no undefined behaviour in that.