Bug 4623 – Non-integer type allowed as static array size
Status
RESOLVED
Resolution
FIXED
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
Linux
Creation time
2010-08-11T11:44:00Z
Last change time
2015-06-09T05:11:35Z
Keywords
accepts-invalid, patch
Assigned to
nobody
Creator
ibuclaw
Comments
Comment #0 by ibuclaw — 2010-08-11T11:44:22Z
The code:
void main()
{
int[0.128] a;
}
Should not compile, rather error with the message stating that either the size of array 'a' has non-integer type, or that the compiler cannot implicitly convert expression (0.128) of type double to uint.
See: http://dstress.kuehne.cn/nocompile/o/opIndex_05.d
Regards
Comment #1 by clugdbug — 2010-09-29T12:43:23Z
PATCH mtype.c, TypeSArray::semantic(), line 3344.
dinteger_t d1 = dim->toInteger();
- dim = dim->castTo(sc, tsize_t);
+ dim = dim->implicitCastTo(sc, Type::tsize_t);
dim = dim->optimize(WANTvalue);
dinteger_t d2 = dim->toInteger();
if (dim->op == TOKerror)
goto Lbaddim;
if (d1 != d2)
goto Loverflow;
... and further down:
Loverflow:
error(loc, "index %jd overflow for static array", d1);
+ Lbaddim:
dim = new IntegerExp(0, 1, tsize_t);
TEST CASE for test suite
//bug 4623
static assert( !is (typeof(() {int[123.1] x; return x; })));
I've done this patch in a relatively complicated way, so that something like:
int[7654321.0] bug4623b;
generates only one error message, not two.
Comment #2 by ibuclaw — 2010-09-29T14:50:14Z
Can't you catch it in the lexer?
Just thinking out loud...
Comment #3 by ibuclaw — 2010-09-29T17:39:15Z
You can catch it in parse.c
@@ -2428,6 +2428,12 @@
{
//printf("it's type[expression]\n");
inBrackets++;
+
+ if (token.value != TOKint32v && token.value != TOKuns32v &&
+ token.value != TOKint64v && token.value != TOKuns64v &&
+ peekNext() == TOKrbracket)
+ error("I should be a an integral value, not [%s]", token.toChars());
+
Expression *e = parseAssignExp(); // [ expression ]
if (token.value == TOKslice)
{
I certainly don't mind either way. Your patch works just great, thanks!
Comment #4 by clugdbug — 2010-09-30T06:26:43Z
(In reply to comment #3)
> You can catch it in parse.c
[snip]
You can, but then it doesn't catch things like:
const float f = 1.23;
int[f] z;
> I certainly don't mind either way. Your patch works just great, thanks!
It looks as though you got that case from dstress. Have you been running the dstress tests? If you have, I'd be very interested to see the results. I believe that all the compiler ICE bugs are fixed, but I have no idea about how many others are still failing.
Comment #5 by ibuclaw — 2010-10-01T11:18:20Z
I haven't ran dstress using the DMD compiler. I think I stumbled upon the case somewhere from an archived message on the ML that probably got forgotten about.
I wouldn't go as far as saying all compiler ICE bugs are fixed just yet (I raised an issue recently with CTFE with a patch supplied, for example), though they certainly are very far and few between now.