This patch fixes a portion of case 1889 in Bugzilla. This patch causes the compiler to report an error when a constant array is declared with an integer literal size that is too big.
I’m new to the code base, so, I’m not sure if I did everything correctly. For example, what is the best way to get the number of bytes of each allocated per element of an array?
Here is the way I’m doing it…
unsigned SizeTypeBits = static_cast(Context.getTypeSize(Context.getSizeType()));
llvm::APSInt EltBytes(SizeTypeBits); EltBytes = Context.getTypeSize(T) / Context.Target.getCharWidth();
If this is right, maybe it could be added to ArrayType?
Also, what is the max address of an array? I can’t find anything in the c or c++ standard about that. I ended up checking a few compilers, google, etc. on this and it seems to be LONG_MAX.
Is this always the case meaning is it different on different targets?
If it is different based on the platform I think it needs to be in the TargetInfo (i.e. llvm::APSInt TargetInfo::MaxStackAddress() const or something).
Additionally, are there different rules about how large an array can be allocated if it is static?
Sadly, this patch doesn’t help with the specific problem for the case in Bugzilla. That case involved an expression that evaluated to larger than maxlong, for example char BigArray[0x7fffffff + 1].
The expression is evaluated in bool Expr::isIntegerConstantExpr and that function has a few FIXME comments:
/// FIXME: Pass up a reason why! Invalid operation in i-c-e, division by zero,
/// comma, etc
/// FIXME: This should ext-warn on overflow during evaluation! ISO C does not
/// permit this. This includes things like (int)1e1000
/// FIXME: Handle offsetof. Two things to do: Handle GCC’s __builtin_offsetof
/// to support gcc 4.0+ and handle the idiom GCC recognizes with a null pointer
So, to patch this problem correctly, I’ll need to know if overflow occurred as opposed to simply an expression that ended up less than zero. I’m going to work on returning various
error codes from the isIntegerConstantExpr, but a change to that method will affect a bunch of different areas, so, I’m sure I’ll need some help! Does anyone have any ideas about how
to handle overflow during the evaluation of expressions?
bug1889.patch (3.8 KB)