This is the mail archive of the
mailing list for the GCC project.
Re: c99 VLA semantics
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
(*)(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
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