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.<br><br>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?  <br>
Here is the way I'm doing it... <br>        unsigned SizeTypeBits = static_cast<unsigned>(Context.getTypeSize(Context.getSizeType()));<br>        llvm::APSInt EltBytes(SizeTypeBits); EltBytes = Context.getTypeSize(T) / Context.Target.getCharWidth();<br>
If this is right, maybe it could be added to ArrayType?<br><br>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. <br>
Is this always the case meaning is it different on different targets?<br><br>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).  <br>
<br>Additionally, are there different rules about how large an array can be allocated if it is static?<br><br>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].<br>
The expression is evaluated in bool Expr::isIntegerConstantExpr and that function has a few FIXME comments:<br><br>/// FIXME: Pass up a reason why! Invalid operation in i-c-e, division by zero,<br>/// comma, etc<br>///<br>
/// FIXME: This should ext-warn on overflow during evaluation!  ISO C does not<br>/// permit this.  This includes things like (int)1e1000<br>///<br>/// FIXME: Handle offsetof.  Two things to do:  Handle GCC's __builtin_offsetof<br>
/// to support gcc 4.0+  and handle the idiom GCC recognizes with a null pointer<br>/// cast+dereference.<br><br>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<br>
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<br>to handle overflow during the evaluation of expressions?<br>
<br>Regards,<br><br>Chris<br clear="all"><br>-- <br>"Like a poet has to write poetry, I wake up in the morning and I have to write a computer program." -- Knuth<br>