> The story is like this:
> - the "pseudo gloabal" declaration of C<f> declares a variable usable in
> both subs. This was invented[1] to cover vars outside of all subs in a
> main execution stream, which is intersparsed with sub declarations, like
> a perl programm could be.
> - both subs "_foo1" and "_foo2" are compiled totally independent. This
> implies: no usage of C<f> and C<x> in "_foo1" do interfere, so they get
> the same register - bumm.
Yuck. I was afraid of this.
> If you want true variables around compilations units, please use globals
> or lexicals if they are in the same lexical pad.
>
> [1] This "feature" is IMHO at the boarders of imcc as the namespace
> instructions is. Should the HL handle these or imcc? But if its as
> confusing as your test case, I would say I'll rather not support this
> inside imcc.
My vote? Rip it out completely. It's *terribly* confusing. (And sends me back to
the drawing board, at a cost of speed.)
To have a name be valid in two scopes because of a single declaration, yet have them
not related in any significant way just boggles the mind. Sort of reminiscent of a
joke "intern" declaration in C I saw once (IIRC):
/* This means that *every* function in here gets an
automagical "auto int foo". Not the same one -- their
own. That way they don't each have to declare it. */
intern int i;
void sub1 () {
i=56; // Variable used only once
return;
}
void sub2 () {
printf("%d", i); // Danger! Use of uninitialized value!
return;
}
void sub3 () {
for(i=0; i<10; i++);
}
int main(int argc, char **argv) {
sub1();
sub2();
sub3();
}
