On Sun, Feb 08, 2009 at 11:52:23PM -0800, Christopher Li wrote:
> > Subject: [PATCH] Handle nested declarators vs. parameter lists correctly
> >
> > Seeing a typedef name after ( means that we have a parameter-type-list
> > only if we are parsing a parameter declaration or a typename; otherwise
> > it might very well be a redeclaration (e.g. int (T); when T had been a
> > typedef in outer scope).
>
> The patch looks great. Applied.
Still leaves a couple of uglies, BTW. One (easily fixed):
int [2]*p[3];
is actually (still) accepted. Nevermind, we just need to set dont_nest
in a few more places (and no, it's not a regression; moreover, similar
crap works with functions instead of arrays).
Nastier one:
#define A __attribute__((address_space(1)))
void (*f)(A int *x, A int *y) = (void *)0;
void g(int A *x)
{
f(x, x);
}
now try test-parsing on it. You'll see that f gets type
void (A *)(int *, int A *);
instead of expected
void (*)(int A *, int A *);
Reason: cretinous gcc grammar is fscked in head. There's a very, _very_
good reason why C doesn't allow e.g.
int (const x);
Consider seeing
void f(int (const
What would that "(const" be? Beginning of parameter list in the first
parameter of f or a beginning of nested declarator in the same? In
C it's the former and we can tell that immediately.
I really don't want to get into the reasons why gcc decided to allow that with
s/const/__attribute__((....))/ - it's too long a flame, but they did and
so we have to do lookahead from hell in parser. Namely, eat all attributes
first and only then decide whether this ( starts a nested declarator or a
parameter list.
... except that we do it wrong and these attributes land on what will by
SYM_FN and not its first parameter.
BTW, the longer I'm looking at that, the less I like the original decision
to use __attribute__ for our extensions. Or continued use of __attribute__
by gcc folks, while we are at it.
One lovely example:
T __attribute__((whatever)) *p;
is NOT pointer-to-whatever-T; it's whatever-pointer-to-T. Which is clearly
not what we want for __user et.al. The only way to get it applied *before*
derivation is, BTW,
T (__attribute__((whatever)) *p);
(and yes, that's where this crap in syntax has come from). Mind you,
T * __attribute__((whatever)) *p;
*is* pointer-to-whatever-pointer-to-T, which makes the situation even more
inconsistent.
While we are at it, our handling of __attribute__((mode(...))) is wrong -
not only
__attribute__((mode(HI)) long x;
is fine, it's actually s16. Moreover,
int __attribute__((mode(HI)) *x;
is only going to work on 16bit boxen, since it's "16bit pointer to int".
64/32bit analogs of that construct *are* used in the wild on some weird
targets.
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
