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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2001-08-08 15:42:57 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!louie!not-for-mail Sender: - From: Bart.Vanhauwaert@nowhere.be Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <9kbvsr$a02@augusta.math.psu.edu> <3B69DB35.4412459E@home.com> <3B6F312F.DA4E178E@home.com> <23lok9.ioi.ln@10.0.0.2> <3B70AB15.35845A98@home.com> User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.2.17-21mdksecure (i686)) Date: Thu, 9 Aug 2001 00:18:34 +0200 Message-ID: NNTP-Posting-Host: 194.78.202.248 X-Trace: 997310576 reader1.news.skynet.be 62255 194.78.202.248 X-Complaints-To: abuse@skynet.be Xref: archiver1.google.com comp.lang.ada:11646 comp.lang.c:73014 comp.lang.c++:81085 Date: 2001-08-09T00:18:34+02:00 List-Id: Warren W. Gay VE3WWG wrote: >> Well, why don't you explain the problem than? (In a modern C++ program >> the only need for variants is interfacing with legacy API's btw) > Go back and read the first post. Then actually spend some time writing a > test program that actually sends different sized messages with msgsnd() > and msgrcv(). Obviously, you've never used these in any language, or you > would already know the problem. ;-) I tend to stay away from legacy API's, yes. > Ada95 does provide facilities for internationalization. But even if the > Enum_Type'Image() facility only comes in ASCII? That doesn't prevent it > from being useful, does it? You're grasping at straws on this one ;-) I am not. Point out a non-contrived use of this feature in a serious (hence i18n'ed) project. This shouldn't be too hard, since you seem to insist on the usefullness of this feature, you must have used it a lot yourself? > Read my response again. I said the "STL is not used in all contexts". I > never said that it not used in all projects as you seem to be replying > to. Indeed, I misread that part. I am sorry, English is not my native language. > In other words, in a given project, with or without the STL, there > will be arrays of one type or another, that exist naked without the > helpful bounds checking of a STL class. The pipe(2) system call was a > simple case where this could occur. This is by no means exclusive ;-) That's basically the same argument as the msgrcv/msgsnd one. Shoot some more (printf/scanf/gets/...). Yes I know about them. I tend to stay away from them. Modern C++ platforms provide better, safer solutions. Once again, the language is a small part of my valuation. You are not forced to use dangerous API's. >> I have never felt the need to know the size of a certain struct. Why >> don't you give an example where it is needed? > What? You've never written a structure to a file? A socket? A message queue? Not on a serious project no. I use human readable files. >> I write code that runs on windows/unix for living. I just grepped through >> my current project (rather small, 500k lines) there is not one single >> sizeof in the code. > That kind of proof won't get very far. That's like trying to prove a > hypothesis with a limited emperical evidence. Anyone scrutinizing this > kind of response, simply has to ask "So?" It is proof that it is possible to write a non-trivial project without sizeof. Which was exactly my point. Yes sizeof (or lack thereof) has been abused. I am sure there are things in Ada that one can abuse. > In case you havn't noticed, there has been some other threads very active > in this regard (or at least in comp.lang.ada). I'm not going to repeat > all of that here ;-) You can find them on your own time. I am reading this from comp.lang.c++ (as you could've guessed) cu bart -- http://www.irule.be/bvh/