On 02/07/2017 10:04 AM, Vít Ondruch wrote:
Dne 6.2.2017 v 19:43 Panu Matilainen napsal(a):
On 02/06/2017 06:51 PM, Vít Ondruch wrote:
Dne 6.2.2017 v 16:00 Panu Matilainen napsal(a):
One open question I have is what to do with %undefine's: currently rpm
allows %undefining anything from any scope, and that is at odds with
any attempt to rationalize and formalize the scoping to something
actually comprehensible. A simple approach is that you can only
undefine something from your local scope or the global scope. But what
if there's something by the same name in between?
What is wrong with this? You always undefine the value from the top of
the stack ...
What do you mean by "this" - the current behavior or the alleged
scoping aware new version?
The current behavior indeed just removes from top of the stack with no
consideration as to who defined the macro and where. And this in a
system that makes claims about scoping...
Right, now I see ... but then I don't understand what you meant by "But
what if there's something by the same name in between?"
Right, maybe an example will make it clearer. Indenting and missing
line-continuation characters are supposed to be for readers benefit:
---
%define foo 1
%define dofoo()
%define foo foo
%undefine foo
%undefine foo
%define dobar()
%define foo bar
%dofoo
echo %foo
%dobar
---
So dobar() defines a local %foo which shadows the global %foo. Then it
calls dofoo() which creates its own local %foo, and then %undefines it
twice. What is supposed to happen in this case?
The way I see it, if we're supposed to have some sort of meaningful
scopes, the undefines in dofoo() cannot possibly affect the definition
of foo in dobar(). So does the second undefine affect the globally
defined foo? That's one possible interpretation, but this is a problem
with the rpm implementation of things as the macros stack globally, so
instead of popping the macro at top of stack, it'd be popping it from
bottom of it because there's the dobar() definition in between.
Without violating the principles of the global macro stack, the only
possible interpretation I see is declaring the second undefine a no-op
(as in try to undefine a non-existent macro). Whether that is sensible
at all is an entirely different question - it almost certainly is not.
It's also quite possible the only sane answer here is "implement a
proper local stack then"...
- Panu -
- Panu -
_______________________________________________
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
