This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 "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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]