This is the mail archive of the gcc@gcc.gnu.org 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]

Variable-sized types vs. templates


PR 5661 is a crash that arises when using a VLA as a template parameter.

Of course, VLAs are an extension to ANSI/ISO C++, so we are outside the
scope of the standard.

Here is the test case from the PR:

 template <class T> struct A{ A() throw() {} };

 struct B {
   static const int s;
   A<int[s]> a;
 };

 B b;

We accept "int[s]" thanks to the extension.  When trying to instantiate
A, we crash.

A purer example is:

 template <typename T> struct A { T t; };

 void f (int i) { A<int[i]> a; }

We happen not to crash on this example -- but we certainly do not do
the right thing either.

(Once again, we see the problem with incorporating extensions without
thinking through how they interact with other language features.  This
is likely not the only problem with variably-sized types.  I'll bet that
`typeid' and `dynamic_cast' do not behave sensibly in conjunction with
these types either.  The argument that GNU C (and now ANSI C) have VLAs
is, in my opinion, totally irrelevant; the C folks thought about what
these things mean in C, but nobody has thought through what they mean
in C++.)

However, I assume that nobody is about to let me remove the extension.

Therefore, we need to define a rule that allows us to diagnose the above
cases.  That's not easy.  For example, if T is a VLA type, or a type
containing a VLA, is "A<T>" ok?  What about "A<T*>"?  (Note that the
template body might dereference something of the pointer type.)  What
about "A<void (*)(T**)>"?  What about "A<S*>" where S is a struct
containing a VLA?

I do not fancy having to recursively walk the type tree every time we
instantiate a template; that will make our already slow template
instantiation process even slower.  Neither do I fancy having to keep
a bit on each and every type as we build them; the compiler creates
types in too many places using too many methods to make this easy to
get right.

Brilliant solutions?

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


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