Re: [nmap-svn] r27929 - in nmap-exp/patrick/nse-lua52: . nselib

[David Fifield <david () bamsoftware com>]

On Fri, Feb 03, 2012 at 05:16:54PM -0500, Patrick Donnelly wrote:
> On Mon, Jan 30, 2012 at 5:35 PM, David Fifield <david () bamsoftware com> wrote:
> > On Thu, Jan 26, 2012 at 11:06:35PM -0800, commit-mailer () insecure org wrote:
> > > Author: batrick
> > > Date: Thu Jan 26 23:06:34 2012
> > > New Revision: 27929
> > >
> > > Log:
> > > Remove stdnse.c submodule for binding nsock_sleep. The function is now available
> > > in the nmap.socket module. We provide an alias in stdnse.lua for compatibility.
> >
> > Why nmap.socket.sleep? What does sleeping have to do with sockets?
>
> Well, nothing.
>
> The reason I moved the function into the socket library is because it
> uses the nsock pool upvalue. It is therefore difficult to export the
> function outside of the module cleanly.
>
> The reason the nsock pool is an upvalue is mostly due to ideological
> concerns. There were 3 strategies for handling library data in Lua
> 5.1:
>
> 1) Putting data in the Lua Registry (LUA_REGISTRYINDEX pseudo-index)
> 2) Putting data in the library environment (LUA_ENVIRONINDEX
> pseudo-index). (most common)
> 3) Putting data in the library closure upvalues (rarely used).
>
> In Lua 5.2, function environments are removed. Instead, everything is
> an upvalue or local ( (_ENV is a main chunk's first and only upvalue).
> The new system pushes for an upvalue based design where library data
> is stored in the upvalues for all library closures. See for example
> lua_setfuncs [1].
>
> As part of the upgrade to Lua 5.2, I decided to uniformly change our
> libraries to use only upvalues for library data. This includes things
> like userdata metatables and the nsock pool (previously stored in the
> Lua registry) and the various caching mechanisms in nsock and dnet
> (previously stored in the LUA_ENVIRONINDEX).
>
> One drawback is that functions like the sleep function and the loop
> function must be accessed as a regular Lua closure, not as a C
> function. So another library such as stdnse.c cannot create a sleep
> function closure because it does not have access to the nsock pool
> upvalue. I argue this is a better design as it reduces coupling
> between our libraries by localizing data access. [Nothing stops us
> from having aliases though.]

Okay, what you say sounds reasonable and better than the current design.
I would prefer to have nmap.sleep be the documented normal sleep
function, even if it's only an alias for nmap.socket.sleep. That it
comes from the socket library is to me only an artifact, an
implementation detail, that callers of a sleep function shouldn't have
to be aware of.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/