How difficult is it to detect at the source code level arrays of run-time boundaries?

Question

Proposal (Accepted) for Runtime Arrays with Automatic Retention Time (N3639) " states that

Stack overflows become more likely, in particular if the size depends on an external input and is not properly checked. Some environments may therefore prohibit the use of this feature. Such a ban can be easily applied using a static analysis tool.

I don’t think forced execution should be simple if the analyzer is required to implement a complete C ++ compiler.

Consider the following code:

template<typename T> inline void array_user( const T& x ) { int a[f(traits<T>::omega)]; } 

It seems to me that the analysis needs to be repeated for each use of array_user<T> and consider:

• Applicable traits<T> specializations can be found at the point of use array_user<T>
• traits<T>::omega - expression of the compile-time constant (either using constexpr or C ++ 03 approaches such as enum )
• Type traits<T>::omega
• If the applicable overload is f() (at the point of use array_user<T> and possibly found via ADL), this is constexpr

Am I missing something? Is it possible to provide such a restriction without going through a full compilation?

Is it possible to write code in such a way as to simplify the verification of the inapplicability of the runtime boundaries?

Answer 1

If I was instructed to write an analyzer to statically verify the non-use of runtime restrictions, I would reject the above code. I would require that all array declarations use either an integral literal for binding, or annotate so that the compiler rejects the execution bounds.

 template<typename T> inline void array_user( const T& x ) { int a[f(traits<T>::omega)]; sizeof a; } 

However, given the number of compilers that currently provide C99-style VLAs in C ++ as an extension, I’m not sure that they will really comply with the C ++ 14 behavior of prohibiting sizeof .