Nmap Development mailing list archives

Re: [RFC] NSE pack/unpack library


From: Fyodor <fyodor () insecure org>
Date: Thu, 19 Jun 2008 17:26:35 -0700

On Fri, Jun 20, 2008 at 12:29:54AM +0200, Philip Pickering wrote:
Hi!

I've started working on a NSE library for handling binary data,
comparable to the perl pack/unpack functions. It's based on the
lpack library and therefore it differs from perl's pack/unpack.

Hi Philip.  Thanks for the details.  I assume that the lpack library
you are starting with is as described at:

http://lua-users.org/wiki/LuaPack
http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/

Are there reasons that we can't use the current lpack library as-is?
When we incorporate third party libraries, it is best to reduce
changes to the minimum necessary.  Among other advantages, that makes
it easy to upgrade them.  When we fix or improve things, it is best to
submit those to the upstream maintainers in the hope that they will
incorporate our changes so we don't have to keep maintaining them.

Of course, sometimes we need functional changes which aren't desirable
upstream.  And sometimes upstream is not maintained and so we end up
maintaining all our changes.  But we try to limit such cases.

Also, I'm not sure there is any need for Perl format compatability,
unless the Perl version is much more powerful in a way which is
important to us.  It may seem that we prefer Perl, since we have a
Perl Compatable Regular Expression library in NSE.  But that was done
because PCRE was already part of Nmap when NSE was added, and Lua's
"patterns" just didn't seem powerful enough for our needs.

Another advantages of limiting the ways that our version diverges is
that we may be able to simply reuse or link to the source library's
documentation.

Now I don't know anything about lpack and I rarely use Perl's
pack/unpack.  So maybe there are important reasons why we need to use
Perl-style.  But if there aren't, I think we should stick with the
format of the source library we use.

Cheers,
-F


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


Current thread: