Nmap Development mailing list archives
RE: C++ Development
From: "Jay Freeman \(saurik\)" <saurik () saurik com>
Date: Sat, 9 Sep 2000 23:35:31 -0500
<added> I had forgotten about having other programs link into Nmap, and that _does_ cause some big problems if nmap is in C++, so I am going to defer to Fyoder's point. However, I decided am going to send this response to Etaoin's message anyway, as there are some questions that I have based on it, and some of the points might be interesting to some people. Besides, I spent a lot of time typing it, and I am going to feel like I wasted a lot of time if I don't send it SOMEWHERE, hehe. Considering I am now going to agree that core nmap development should be continued in C, the sections marked digressions are even more digressions than they were before before :). I'm really interested in responses to the points about "what goes into nmap" sections (which are marked <important/>). Oh, and to comment on Fyoder's point #3 quickly: I wasn't suggesting building a new nmap from scratch. I was simply thinking that a slow migration towards a C++ code base might be desirable, slowly swapping out this with a C++ part there, and this with one there, etc. </added> ------------------------------------ My responses to your comments are inline. The really important bits are marked as <important/> and the all out digressions are labelled as <digression/>. Sincerely, Jay Freeman (saurik) saurik () saurik com
-----Original Message----- From: shrdlu () cnchost com [mailto:shrdlu () cnchost com]On Behalf Of Etaoin Shrdlu Sent: Saturday, September 09, 2000 10:00 PM To: Nmap-Dev Subject: Re: C++ Development "Jay Freeman (saurik)" wrote: [some very well written, and quite lengthy, arguments as to why nmap might be moved to C++]So I?m sitting here working on nmap+V, I?m thinking to myself?man, I wish Iwas working in C++?. I finally ask (for the umpteenth time),?Why aren?tI?? That?s the question I am posing to this list :-).I am leaving in the first couple of lines, so that you might thing about tightening up the rules on your Outlook (all the funny question mark things are those special MS characters that don't really transcribe too well). I left them in to make a simple point.
Personally, I like those characters :). I hope this response will be more to your stringent likings.
While it might seem useful to add in the complex and rich language of C++, instead of using the more restrictive C, the baggage that comes along with it brings unexpected extras that might not fit in with the purpose of the tool. I am already beginning to find nmap growing large. I see many proposed functionalities, such as application/port determination, but at least these are optional add ons.
<important> OK, so you would rather keep all this stuff out of nmap. That's a rather useful opinion. What are your thoughts on some of the features that are already in nmap? IP Protocol scan? RPC scan? Those seem to go away from the original concept of just having a port scanner. Maybe what is needed is more feedback here about what is even ending in nmap in the first place. </important>
Not everyone is a fan of C++. I consider it to be a garbage language, although I liked it (and used it) in some of its earlier incarnations. It is not as though it is a separate language from C, but is rather quite dependent on it. Much of the claimed improvements from such things as STL are just that: claims. When I compare similar code written in C++ and C at the assembler or machine code level, the C++ is less efficient. With a tool such as nmap, efficiency counts.
<digression> This is EXACTLY what I'm talking about. Someone who did work in C++ "in some of its earlier incarnations" and now seems to have a vendetta against it. Yes, some stuff is going to be more inefficient at the assembly level. Yes, you could definitly make a more efficient anything than STL provides. The real question is: did you? Nmap didn't. It has some optomizations in it, but most of what it does isn't the most efficient way to do it (and I don't mean "most" like "most" possible, I mean it in a relative sense). </digression> <important> BTW, here is the real crux of the problem. Does it count? In Nmap, of all tools, does every last drop of power that can be squeezed out of the compiler count? We aren't talking about orders of magnitude here. Maybe I'm not using Nmap the way other people are, but I've never needed more speed out of it. I even go as far as to purposely sacrifice speed by using a non-parallel implementation of a dinky language I wrote for scanning ports and determining what is running on them (nmap+V). The only time I sit around staring at Nmap wondering "man, this sucks" is when Nmap can't scan the remote host for whatever reason, and doesn't know that it can't. <important> I would be much happier making the scan last longer, but have 5 more ways of getting information from the remote host, one of which having the possibility of telling Nmap: "this scan is going to make you go crazy and take an hour to complete because this host is purposely blocking this kind of scan, or is running an OS that doesn't support it, don't waste an hour sitting there pretending to try it just to return that all the ports are 'open'". This would go a long way towards speeding up scans than a small amount of low-level efficiency ever could. Unfortunatly, in its current state, the chance that Nmap will ever have something like that is minimal. Every time someone has come up with anything that isn't a blanket scan (such as IP protocol, or the RPC scan), something that only has special circumstances where it is useful, like the Cisco scan I always use in my examples, it has been denied by Fyoder, a decision I agree with. Right now, Nmap can't handle a bunch of special purpose scans (which would be required for most of the cases of "scans don't work here"), no matter how useful they might be. The code base would just become too difficult to deal with for the major maintainer: Fyoder. </important> </important> <digression> Most of this could be elieviated by rearchitecturing it and leaving it in C. I agree with that. But you could go a lot farther if you could have complete encapsulation of scoping and had cleaner syntax for just about everything, including memory allocation... I'm sick of looking at malloc() calls. </digression>
If this were a large "software engineering" project, requiring multiple bodies, and design experts, and all that other claptrap from the 70s and 80s, something like C++ helps to keep everyone in the same camp, on the same road, and singing the same tune. It occupies the place that Ada had been expected to, and doesn't do too bad a job of it.
<important> This _is_ a "software engineering" project. Fyoder isn't the _only_ person working on Nmap. There are lots of people out there, _all_ working on Nmap. Finding this bug, contributing this feature, or that optomization. Nmap has the potential to be a really large, very important project, capable of doing just what it claims to: network map. The real question is: does Nmap realize that. I think it does. I believe Fyoder realizes that, based on all the conversations I've had with him and everything he has stated on the list. A lot of other people out there do as well, as can be extrapolated from the discussions of modularizing Nmap, and the shear fact that people bother to put together the new functionality in the first place. </important> <digression> I understand that you like C, and I agree that you can achieve almost the same abstractions in C as you can in C++. The question is, do you want to? After all that the world has learned, do you care enough to hoist the flag of C over your head and believe that you have the "last language". That's the question we, as programmers, must all ask ourselves at some point. But I digress :). </digression> <important> If what you are really saying is that you want Nmap to be a small project developed almost solely by one person that does only a few core bits of functionality, then OK. I understand your arguments. I don't agree with them, but I understand where you are coming from on every one of your points. Yes, efficiency matters, we can gain code clarity by just chopping out the parts we don't need, and not adding anything else that isn't essential in the future. </important>
Anyone out there mind helping me understand why people don?t like C++?I would have been one of the people answering the survey who claimed that C++ sucks. My opinion hasn't changed. When I interview someone, I ask which language they learned first, and it counts against them if it was C++, then C, rather than the other way around (not much, but it can be a deciding factor).
<digression> <digression> I'm quite the opposite. I've always found that people who learned C first think in C first, and never quite "get" the OOP way of doing things. I am often used by a company I work for, as well as my college (and occasionaly my old high school) to make decisions about programmers and what their capabilities are. To me, there are two big hits you can have against you: you don't know C++, you learned C before C++ and use it for everything. </digression> </digression>
As I mentioned, C++ can?t do anything C can?t, and C++ isn?t even that fundamentally different from C (as ?objects? can be built asstructs with?methods? that take pointers to the struct); but having STL andI/O streamscan make things much easier over the ways the equivalents are usually implemented in C.Here you are mistaken. The footprint for C is much smaller than C++, due to the libraries that you don't need to include. You can write clean, well formed code in C, without classes (use struct instead), and without all of that terrible overhead and obfuscation that seems to be part and parcel of C++. Sure, memory handling can be better in C++, but forgetting to free memory in C++ is just as disastrous as in C, and just as easy. Array overruns, infinite loops, and any other problems you might think of exist equally in both. At least with C, I know that it will compile everywhere, and I know where to find the libraries for it.
Wasn't claiming that C++ did that, just that if need be, a developer could do that in C and make it have similar syntax and equivilant functionality as C++ objects. The paragraph you quoted was a block to keep you from bringing up that argument by bringing it up myself. My point was that having STL and I/O streams means I don't have to have all sorts of linked list or dynamic array management code in my program. <digression> Obfusication?!? Where are you getting this stuff from? I would MUCH rather look at C++ code than C code with pseudo-objects. Things like being able to declare my object on the stack, AND call its constructor, and having its destructor called AUTOMATICALLY when it goes out of scope. Let's see... have a pointer, call a pseudo-constructor, allocate on the heap, use "->" instead of ".", then explicitly call the destructor in the end... no.... Maybe have my pseudo-constructor call take a pointer to an already existant memory area, but then I need to always allocate memory up front and I still need to call my destructor. </digression> Once again, I don't consider C++ a magical solution. I do NOT CLAIM that it helps with memory management and keeps you from making stupid mistakes. I did not, I will not, and I do not now. I claim that it has easier syntax, that it already has abstractions of various data structures that are reletively efficient... MORE EFFICIENT than what most people would build off the top of their heads (which is how most of nmap is written), EASIER to swap out later when you realize that linked list really should be a tree because now we need to search it.
I have had years of experience with multiple languages, everything from CDC Compass (for the Cyber) to PIXAR assembler for the CHAP (that was a GREAT machine, I loved it), from PASCAL to SNOBOL, and from LISP (more dialects than I care to name) to C++. Please, leave nmap in C. You can make all the C++ additions you want -- it's not like it won't compile for you. Sorry for the novelette, guess you touched a nerve. .shrdlu -- Computer security is an oxymoron. Prepare for the worst. -- Bruce Schneier
--------------------------------------------------------------------- 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).
Current thread:
- C++ Development Jay Freeman (saurik) (Sep 12)
- Re: C++ Development Matthew Franz (Sep 12)
- Re: C++ Development Etaoin Shrdlu (Sep 12)
- RE: C++ Development Jay Freeman (saurik) (Sep 12)
- RE: C++ Development Fyodor (Sep 12)
- RE: C++ Development Stou Sandalski (Sep 12)
- RE: C++ Development Jay Freeman (saurik) (Sep 12)
- RE: C++ Development Stou Sandalski (Sep 12)
- Re: C++ Development Etaoin Shrdlu (Sep 12)
- Re: C++ Development Eric Anderson (Sep 13)
- RE: C++ Development Jay Freeman (saurik) (Sep 12)
- Re: C++ Development H D Moore (Sep 12)