From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2001-08-10 07:16:43 PST Path: archiver1.google.com!news2.google.com!newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ From: Ted Dennison References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <9kbvsr$a02@augusta.math.psu.edu> <3B69DB35.4412459E@home.com> <9kp9n7$ivm$1@nh.pace.co.uk> Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. Message-ID: <21Sc7.5176$NJ6.23960@www.newsranger.com> X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Fri, 10 Aug 2001 10:16:30 EDT Organization: http://www.newsranger.com Date: Fri, 10 Aug 2001 14:16:30 GMT Xref: archiver1.google.com comp.lang.ada:11762 comp.lang.c:73401 comp.lang.c++:81540 Date: 2001-08-10T14:16:30+00:00 List-Id: In article , Bart.Vanhauwaert@nowhere.be says... > >Ted Dennison wrote: >>>for (std::vector::iterator i=v.begin(); i!=v.end(); ++i) >> That's actually pretty close, and seems to have all the benifits Marin was >> touting. Its a shame I've never seen it "in the wild". :-) > >I use it all the time (and love it) I don't do C++ much, but it does happen. So I'm certianly putting it in my bag-o-tricks (speed be damned). >> o In the Ada version, "i" would not be assignable within the loop. This >> allows the compiler to optimize things a lot more easily. > >I am not really sure, why do you think that? There is no (legal) possibility of aliasing, so it can *always* be kept in a register. If the bounds are static (which they ususally are in an Ada "for" loop that iterates through an array), it can even figure out at compile time exactly how many loops there will be, and unroll (or not) accordingly. A really clever optimizer might even be able to do sexy stuff like set the BPU to the right value just before the loop is ready to fall out. All this can be done with C++ too, of course. But it would be a lot more work for the compiler to figure out if it would be safe to do so. >> Also, remember that all of us are not application programmers. Marin and I >> are systems programmers. I get quite suspicous of any *dynamic* data >I guess that's why you use Ada and I use C++? Best tool for the job >and all that? I suppose you could say that. But then, Ada doesn't exactly have problems with dynamic data structures either. It just doesn't require them in a lot of places where C does. There's still nothing stopping you from using them if you really want to. You just have more options. However, I do have to admit that Ada is really more of a "dream language" for systems programmers. For applications, it drops down to meerly being a fair bit better. :-) (Which isn't really enough for a lot of people) >However, predictability is achievable in C++ just as well as in C. >For example all containers in the STL have an allocator as template >argument. So if you need predictable memory allocation you can >override the standard allocator and for example use memory from a >pre-allocated pool. I'll admit it is quite possible, in theory, to have nice predicitable allocators and deallocaters. But for the most part, real-time programmers (and kernel programmers, I'd imagine) avoid *any* dynamic allocations at all during runtime like the plague. Even a good regular memory manager is going to take much longer than a stack allocation and/or deallocation (which just involves moving the stack pointer). To make matters worse, most OS'es (even RTOSes) *don't* come with a good one. Thus all data typically gets allocated either at startup time, or on the stack at runtime. Where I work, having a runtime dynamic memory op discovered in your code is typically a one-way ticket to the doghouse. :-) >> Systems software is pretty much what this thread is about. In particular, one >Is it? I approached this thread from the application programming side. Well, the topic is avoiding security problems like the Code Red worm. Worms like this one use security holes in the OS (and near-OS systems software like email servers and webservers). So yes, it is pretty much all about not using unsafe languages to write Systems Software. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com