Re: C++ Development

[Fyodor <fyodor () insecure org>]

On Sat, 9 Sep 2000, Jay Freeman (saurik) wrote:

> ?Actually, Fyoder seems like he would greet the process.  The reason he had
> that question on the survey in the first place was because he was thinking
> of moving nmap to C++ some day, a point he explicitly stated on the survey
> itself (a quote: ?Fyoder may move Nmap to C++?).

Well, I was testing the waters.  But I was mostly thinking in terms of
future projects and optional additions to Nmap.  I would not move core
Nmap to C++ & STL without some very convincing reasons.  Here are some
main reasons for that:

1) Can make linking much more difficult.  At some point, I might put out a
libnmap.so so that people can easily add Nmap functionality (OS detection,
port scanning, raw packet sending, etc) to their applications.  First of
all, this would require that all the applications using it to use a C++
compiler.  Also, C++ compilers do not seem to have standardized symbol
mangling.  For example, if libnmap.so is compiled with g++, it will
probably not work with programs compiled with SUN Workshop.  I even have
problems linking to shared libraries compiled with different versions of
g++.

And those are just the problems you can have trying to link C/C++ code to
C++.  A lot of people would like to bind Nmap functionality to Perl,
Python, Java, etc.  I think you will find this to be much easier if
libnmap is all C rather than C++.

2)  Requiring C++ compiler & STL blocks out a lot of people.  Hell, I even
had to take out lex/yacc requirements from the latest version of Nmap
because so many people didn't have them (or had broken versions).  But
more importantly -- look at projects like Trinux ( http://www.trinux.org
).  They put the Linux kernel and a _bunch_ of cool security/network
utilities and applications on a _floppy disk_.  I seriously doubt the
trinux disk has STL support.  And if use much STL & link it staticly, Nmap
would probably not even fit _by itself_ on the disk.

3) Nmap is already written and many parts have stabilized over years of
debugging based on reports by thousands of users.  Surely a new version
would introduce some bugs and the debugging process has to start over.  
Also there have been many algorithm optimizations and tweaks which may be
lost in the conversion.

That being said, I am not saying that C++ has NO place in Nmap.  If
someone wrote some really cool extensions to NmapFE in C++ and sent me a
patch, I would probably integrate them.  This is because it is an optional
component and plus people who have X and GTK progably have a C++ compiler
too.

I might accept C++ (and maybe even STL) patches to Nmap if they were cool
enough.  But would likely prefer that they modify configure so that they
are just not compiled in if the user lacks the neccessary infrastructure.

I have to say that I do find some of the C++ features to be rather handy.  
My next security program (ncrack) (not finished yet) uses C++.  But I
couldn't stomach requiring STL so it uses Glib (www.gtk.org) instead for
prewritten data structures and utilities.

While, I think Nmap could use better organization in some places, I don't
think it needs C++.  Projects like Apache, the Linux Kernel, and gcc are
orders of magnitude bigger and they seem to get along fine by using C with
a very disciplined approach.

Cheers, 
Fyodor






---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).