Re: Globals (more ruminations)

[Patrick Donnelly <batrick@...>]

On Sun, Jul 11, 2010 at 10:20 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Patrick Donnelly:
>
>> This has been an insidious problem for us and I've had to write
>> custom scripts to look for these accidental global accesses. It
>> would be *superb* if there were some sort of compile time solution
>> to this.
>
> Do you think it would be an issue if scripts still could create and
> update a variable such as http.socket?  That would be a non-global
> access at the bytecode level, but it still would introduce coupling.

We don't look at global accesses in scripts because we give each
script its own global table. That doesn't stop them from creating an
http.socket variable as you point out. Script writers haven't done
this though and I see no reason to worry about it. Our documentation
has established places to put persistent or shared variables (a table
in the nmap module). We haven't had problems with them not using it.

> Should modules be read-only from a user's point of view?

Personally I feel scripts shouldn't be able to modify a module's
table; however, again, we haven't had problems with scripts doing this
so no reason to make a change.


Usually the problem we see is a library writes to a global (and then
later reads it) that should be local. I agree with Roberto that
unintended global writes are the problem.

-- 
- Patrick Donnelly