[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in swit

From: Michael Matz
Subject: Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
Date: Fri, 11 Mar 2016 18:37:30 +0100 (CET)
User-agent: Alpine 2.20 (LSU 67 2015-01-07)


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
  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).

P.S: Oh, and the dynarray API and usage is super ugly ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]