I think the code qwarns you if you are likely to have problems.
==John ff

Funnily enough, in my original documentation and example for pvsmaska, I 
gave an example of overwriting an fsig. Not sure why that got changed. 
A pvs opcode computes at most once per k-cycle (and most usually once 
per N k-cycles); there should be no "consequences for the performance 
loop". In practice, all one has to do inside the code is to avoid 
reading the input arg (per bin) more than once when also writing the 
output. Musically there may well be opcodes where overwriting is 
probably not useful, but it should not actually break anything in the 
sense of causing a crash, blowup, slowdown or anything.

Richard Dobson

Andres Cabrera wrote:
> I think what it means internally is that  both input and output are the 
> same space in memory, so you might be modifying to the input before it 
> has been completely read. The effects of this are hard to predict.
> 
> Cheers,
> Andrés
> 
> On Fri, Jul 25, 2008 at 10:55 AM, David Akbari  > wrote:
> 
>     Hi List,
> 
>     On certain pvs* manual pages, I'm seeing text like this
> 
>     "(!) Warning
> 
>     It is unsafe to use the same f-variable for both input and output of
>     pvs opcodes. Using the same one might lead to undefined behavior on
>     some opcodes. Use a different one on the left and right sides of the
>     opcode. "
> 
>     Why is this not safe? Will the use of pvsinit avoid this type of
>     "undefined behavior"? What exactly is this "undefined behavior" and
>     how does it affect the performance loop?
> 
>