Hi,
On Fri, 11 Mar 2016, Amine Najahi wrote:
> Perhaps surprisingly, correcting this bug is quite costly. Here is a
> tentative patch. I find it messy but working with dynamic data and
> passing the cases to the block function are necessary to handle an
> "unlimited number" of cases and nested switch blocks.
>
> Also, since the 'block' function is starting to have too many arguments,
> I suggest to create a structure that assembles related arguments such
> that def_sym, case_sym, cases, and cases_cnt, and any other...
>
> Does that sound ok?
I'm not a big fan of this solution. First, the bug can't be as MAJOR as
the subject wants to make us believe. After all it wasn't noticed since
the last $MANY years. Secondly it's inherently costly (as you notice) to
do such checking in a single-pass compiler; that's simply expected of the
approach that TCC takes to reach the speed. Third, you don't handle the
GNU extension "case 1 .. 3" at all. I think you handle this correctly:
switch (a) {
case 1:
switch (b) {
case 1: break; // no error here
}
break;
case 1: break; // but an error here
}
so, that's nice. But still, I don't think it's worth it. (Hey, in a way
not erroring is even sort of logical, the error is only there because the
standard requires it; but if looking at the mirrored situation in an
if-cascade, "if (a == 1); else if (a == 1);" there's no error required).
I think there are quite many required diagnostics we don't do because of
the single-pass nature and I don't see why this one only should be fixed.
Perhaps I could be convinced by some speed measurements on a relevant
source base (not only tcc itself).
Ciao,
Michael.
P.S: Oh, and the dynarray API and usage is super ugly ;-)
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
