Nmap Development mailing list archives
Re: [nmap-svn] r27929 - in nmap-exp/patrick/nse-lua52: . nselib
From: David Fifield <david () bamsoftware com>
Date: Thu, 2 Aug 2012 19:11:16 -0700
On Sun, Feb 05, 2012 at 11:59:28PM -0800, David Fifield wrote:
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.
I mistyped when I wrote the above message; I meant that I prefer to have *stdnse.sleep* be the documented function, as it has been historically, not nmap.sleep. In r29466 I undeprecated stdnse.sleep. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: [nmap-svn] r27929 - in nmap-exp/patrick/nse-lua52: . nselib David Fifield (Aug 02)
- Re: [nmap-svn] r27929 - in nmap-exp/patrick/nse-lua52: . nselib Patrick Donnelly (Aug 05)
- Re: [nmap-svn] r27929 - in nmap-exp/patrick/nse-lua52: . nselib David Fifield (Aug 07)
- Re: [nmap-svn] r27929 - in nmap-exp/patrick/nse-lua52: . nselib Patrick Donnelly (Aug 05)