More warn_create_global warnings

More warn_create_global warnings

[Frank Terbeck]

Hey workers!

With the new warn_create_global behaviour, here is another warning that
seems bogus:

zsh% foo() { setopt warncreateglobal extendedglob; local f=bar; : ${f:#(#b)b(*)}; }
zsh% foo
foo: array parameter match created globally in function foo
foo: array parameter mbegin created globally in function foo
foo: array parameter mend created globally in function foo


Do I have to mark those local before using back tracking? Or could those
maybe be created in local scope unless they already exist?


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: More warn_create_global warnings

[Peter Stephenson]

[still on my phone with limited bandwidth...] 

> Do I have to mark those local before using back tracking?

Yes, if you don't want a warning. 

>Or could those 
> maybe be created in local scope unless they already exist? 

We don't know what scope you need them in.  You might have a utility
function in a script that needs to pass them back. It would be extremely
annoying to have to unpick this when the lack of a local wasn't actually
a problem.

Automatically set variables like these are particularly susceptible to causing
problems if you don't get the local in the right place.  That's because
they can be used at multiple levels in various different ways.

By contrast, variable names you pick yourself are less likely to cause
problems.

So if you don't want a warning here, it could be a sign you don’t really
need the warnings at all.

pws

Re: More warn_create_global warnings

[Bart Schaefer]

On Dec 30,  6:17pm, Peter Stephenson wrote:
}
} So if you don't want a warning here, it could be a sign you don't really
} need the warnings at all.

The problem has become one where user A wants the warning, user B does
not, but user A wants to run scripts/functions written by user B.

Sometimes "user B" is the zsh distribution, which hasn't been (and is
rather difficult to be) rigorously checked for undeclared locals.

Hopefully the change in commit 7611e78ad1a8edbfcb486b19d4cfbc969ce1e771
to cause "emulate" to reset WARN_CREATE_GLOBAL will make this less of
an issue, come 5.3 ... but it still means user B has to remember to
properly "emulate"-ify his functions.

Re: More warn_create_global warnings

[Daniel Shahaf]

Frank Terbeck wrote on Wed, Dec 30, 2015 at 15:20:37 +0100:
> zsh% foo() { setopt warncreateglobal extendedglob; local f=bar; : ${f:#(#b)b(*)}; }
> zsh% foo
> foo: array parameter match created globally in function foo
> foo: array parameter mbegin created globally in function foo
> foo: array parameter mend created globally in function foo

You used to have to 'local' both mbegin,mend,match and MBEGIN,MEND,MATCH [1].
I'm not sure whether that's still the case in latest master (couldn't
reproduce it, but maybe I wasn't trying right).

Cheers,

Daniel


¹ https://github.com/zsh-users/zsh-syntax-highlighting/commit/d3deffbf46a45250a399bea86a66cbdd14e12edc

Re: More warn_create_global warnings

[Bart Schaefer]

On Dec 31, 12:49am, Daniel Shahaf wrote:
}
} You used to have to 'local' both mbegin,mend,match and MBEGIN,MEND,MATCH.
} I'm not sure whether that's still the case in latest master (couldn't
} reproduce it, but maybe I wasn't trying right).

Not exactly.

You need local for mbegin, mend, and match to use the (#b) glob flag.

You need it for MBEGIN, MEND, and MATCH to use the (#m) flag.

You need all six parameters declared local only if using both flags.