[cfe-dev] Implicitly declared K&R parameters.

Douglas Gregor dgregor at apple.com
Wed Sep 29 13:31:35 PDT 2010


On Sep 29, 2010, at 12:42 PM, Enea Zaffanella wrote:

> Douglas Gregor wrote:
>> On Sep 29, 2010, at 5:11 AM, Enea Zaffanella wrote:
>>> Hello.
>>> Consider the following K&R function definition:
>>> void foo(implicit, explicit) int explicit; {}
> 
> [...]
> 
>>> bool implicit = (param.getLocation() == param.getTypeSpecStartLoc());
>>> This was working as expected on the few tests we tried. However, we
>>> would like to avoid making wild guesses: is such a property a valid
>>> (i.e., supported) clang invariant or is it just working by chance?
>> It probably comes from building a "trivial" TypeSourceInfo for the
>> parameter type, using the location of the identifier. It's somewhat
>> of an accident, but it's also unlikely to change.
>>> For clarity, would you accept the addition of a method
>>> bool ParmVarDecl::isImplicitIntKNRParameter() const { return
>>> getLocation() == getTypeSpecTypeLoc(); }
>>> ?
>> There are likely to be other implicitly-generated ParmVarDecls that
>> are likely to be caught by this, e.g., the ParmVarDecls for an
>> implicitly-generated copy constructor or copy assignment operator. At
>> the very least, this should check that getLocation() is valid and
>> that the parameter is from a K&R function definition.
>> However, I do wonder you're really trying to solve the larger problem
>> of "implicit int", which would likely require something completely
>> different. For example, here's some ugly C89 code:
>> f(x, y) { register z = x + y; return z; }
>> We'll don't keep track of the implicit int in f, x, y, or z. So,
>> while I'm not opposed to the method you're suggesting (with fixes), I
>> think it's only solving part of the problem that you're probably
>> working on.
>> - Doug
> 
> If we _always_ have a (trivial) TypeSourceInfo,
> then the "implicit int" could be detected by checking
> 
>  const WrittenBuiltinSpecs&
>  BuiltinTypeLoc::getWrittenBuiltinSpecs() const;
> 
> In C, if the (return) type is int and there is no written type specifier and no written sign specifier, then it must have been an implicit int.
> But what if we do not have a TypeSourceInfo set?


Then we should fix it, so that the TypeSourceInfo is always set in these cases.

	- Doug



More information about the cfe-dev mailing list