c99 VLA semantics

Mike Stump mrs@apple.com
Sat Jun 17 00:22:00 GMT 2006


On Jun 16, 2006, at 3:31 PM, Mark Mitchell wrote:
> However, cp/pt.c:check_instantiated_args wants the current definition;
> we don't want to try to instantiate a template with an argument of  
> "void
> (*)(int (*)][foo()]".  I think Mike's patch would have to include an
> audit of all existing uses of the predicate, many of which are
> presumably checking that "there are no VLAs anywhere in here".

As luck would have it, someone else called for an audit of all the  
existing code, so I checked them all...

Ok, just audited things and Fortran seem benign, I think for C,  
Objective-C, Objective-C++ and C++ we are fine, and for Ada, there is  
ample evidence to require an explicit Ok from them before I put it  
in.  treelang doesn't seem to care, and java doesn't seems benign as  
well, though, would be nice to hear from them,  I think that's all  
the languages.

There is the whole inlining semantic that it might be nice to hear  
back from an inline expert on.  We remap decls and types if they are  
variably modified.  I say no it is not a VM type more often, so  
something about inline might care.  A nested function expert might be  
able to spot an edge case we care about.

For any language front end found to want to make make these types VM,  
they can add the clause I too out back to their lang hook.  Ada might  
do this for example.  In C++ there are some uses, but I think they  
are all ok, any edge case can be fixed in the same way.

I tried to find a testcase that would show a difference in behavior  
for C++ and could not find any.  Existing checking code ensures all  
types of nastiness that I wanted to sneak into the compiler were  
caught, the remaining that I could get in, failed later on with the  
same net result.  Can you come up with a more complete sketch for a  
test case?



More information about the Gcc-patches mailing list