Re: [Csnd-dev] instr0 non-globals affecting variable assignment in instruments

It would sound complicated to me to maintain a behaviour where one variable
name maps to two different slots of memory. I feel the way globalVarPool
and instrVarPool in csound7 is designed nicely but perhaps how it was
designed in csound6 it allowed this edge case to go unnoticed. I leave to
the voice of the people of csound what we want to happen here. But my view
would be that redeclaring a variable name of different type should be an
error. It's not only difficult to maintain ambiguity in memory but it also
makes the code difficult to read and understand.

On Mon, 8 Dec 2025 at 01:54, Richard Knight <[email protected]> wrote:

> I'm moving to Csound 7 and some of my collection of UDOs don't work -
> there are some patterns such as the one below in some files, which
> caused compilation to fail with the following error:
>
> error: Array variable name 'Sresult' used before as a different type at
> line 14
> SEMERR: Array variable name 'Sresult' used before as a different type at
> line 14
>
> I can see why this is happening (conflicting types of Sresult) and how
> to work around, but is this expected behaviour?
> Notably this seems to only occur only in opcodes and if arrays are
> involved - if I move the contents of the opcode into an instr then it
> works OK, and numeric/string primitives work OK in this pattern.
>
>
> Sresult = "anything"
>
> opcode test1, S[], 0
>          Sresult[] fillarray "t1", "t2"
>          xout Sresult
> endop
>
> instr 1
>          Sresult[] test1
> endin
>