Re: [Csnd-dev] switch statement verification

Hlöðver Sigurðsson <[email protected]> Tue, 21 Oct 2025 10:48:41 +0300
Newsgroups gmane.comp.audio.csound.devel
Message-ID <CAB8vR8JcrjmGA84AtHgXXMv+1U-cjXWJJB2LLGVx5zH+R-O1xg@mail.gmail.com>
that's a good idea to improve the semantics checker. I could look into it,
made a ticket https://github.com/csound/csound/issues/2316

On Tue, 21 Oct 2025 at 08:56, Scott Sitar <[email protected]> wrote:

> Hello,
>
> Based on the discussion around the switch statement and whether there
> should be an implicit break or not, I've been learning about how it's
> expanded out during compilation to see how hard it would be to implement
> something like a golang "fallthrough" opcode.  I ran into the following
> interesting example, where it seems like we don't insist that the default
> case comes last, and we allow multiple default cases (only the first will
> match).  Should we be more strict, and implement some of these rules inside
> a verify_switch_statement(), similar to the looping opcode verifications?
> We could also put the rule in there to enforce the fallthrough opcode being
> the last opcode of the block, and disallowing it in the default block.
>
> I've pasted the example I was playing with at the bottom.  I'd be happy to
> work on the verification and/or the new opcode if folks think it's
> worthwhile.
>
> Best,
> Scott
>
> =========
>
> <CsoundSynthesizer>
>
> <CsOptions>
> -o dac
> </CsOptions>
>
> <CsInstruments>
>
> instr 1
>     switch p4
>         case 2
>             prints "got 2\n"
>         default
>             prints "got default\n"
>         default
>             prints "got the second default\n"
>         case 3
>             prints "got 3\n"
>     endsw
> endin
>
> </CsInstruments>
>
> <CsScore>
> i1 0 1 3
> </CsScore>
>
> </CsoundSynthesizer>
>