linux-kernel - Re: [-mm patch] make types.h usable for non-gcc C parsers

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: <Pine.LNX.4.64.0708281508540.23011@wotan.suse.de>
Date:	Tue, 28 Aug 2007 16:19:48 +0200 (CEST)
From:	Michael Matz <matz@...e.de>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Adrian Bunk <bunk@...nel.org>,
	Gabriel C <nix.or.die@...glemail.com>,
	linux-kernel@...r.kernel.org, Olaf Hering <olh@...e.de>,
	netdev@...r.kernel.org
Subject: Re: [-mm patch] make types.h usable for non-gcc C parsers

Hi,

On Tue, 28 Aug 2007, Sam Ravnborg wrote:

> Googeling I did not find a good description of where __extension__ can 
> be used so I fail to see where in the parse.y file I shal add the 
> keyword. I think __extension__ may be used both as a part of an 
> expression AND as part of a typedef (as in this case) but I wonder if 
> this is where it is limited to be used.

The grammatic rules involving __extension__ are these (the lhs stems from 
the standard directly):

   external-declaration:
     __extension__ external-declaration

   struct-declaration:
     __extension__ struct-declaration

   nested-declaration:
     __extension__ nested-declaration

   unary-operator: one of
     __extension__ __real__ __imag__

The first three allow to put __extension__ in front of any external or 
local declaration (including decls inside blocks, in C99), ala:

  {
    x = 1+3;
    __extension__ int y = 3;
    x += y;
  }

the last one defines __extension__ as an unary operator, which can be 
applied to all cast-expressions (which in turn are just unary 
expressions).  E.g.:

   x = 1 + __extension__ (2+3);

Note that the decls include the C99 nested-decls in for statements:

   for (__extension__ long long i = 0; ...)

Note further that there's a small ambiguity in parsing when just looking 
forward one token, namely between decl and expression, like in this 
example:

   { __extension__ int i;

vs.

   { __extension__ i + 2;

Here you can't decide if __extension__ introduces an expression or a decl.  
Probably doesn't matter for your parser.  Hope this helps.

Ciao,
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/