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 22:30:23 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!news-out.worldnet.att.net.MISMATCH!wn3feed!worldnet.att.net!24.0.0.38!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc2.on.home.com.POSTED!not-for-mail Message-ID: <3B721FF5.B7D854F6@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 09 Aug 2001 05:30:22 GMT NNTP-Posting-Host: 24.141.193.224 X-Complaints-To: abuse@home.net X-Trace: news1.rdc2.on.home.com 997335022 24.141.193.224 (Wed, 08 Aug 2001 22:30:22 PDT) NNTP-Posting-Date: Wed, 08 Aug 2001 22:30:22 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:11662 comp.lang.c:73084 comp.lang.c++:81150 Date: 2001-08-09T05:30:22+00:00 List-Id: Bart.Vanhauwaert@nowhere.be wrote: > 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. OK, but you're not always given a choice in that ;-) You've managed to live a sheltered life then. > > 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? type Colour is ( Red, Green, Blue ); Background : Colour := Red; ... begin -- Debug : Put_Line("Background = " & Colour'Image(Background)); One Put_Line statement using the Colour'Image() attribute allows me to conveniently print out the value of the enumerated type in human readable terms. To do this in C++, you'd either choose between printing the "integer" value of it, and going back to the include/declaration to figure out what it was, _or_ you'd have to do: static char str_colours[] = { "red", "green", "blue" }; enum { red, green, blue } colour; colour c = blue; printf("colour = %s\n",str_colours[c]); ... which only works if your enums start from zero. Otherwise, you additionally have to map it : static char str_colours[] = { "red", "green", "blue" }; enum { red=100, green=200, blue=300 } colour; colour c = blue; // the following is hopeless, and won't work : printf("colour = %s\n",str_colours[c]); before you object to that, let me add that enums are used with all sorts of weird values -- not all of them start from zero. In fact, if they all did, you'd have a harder time detecting runtime errors due to mismatched use of enums. I purposely choose different starting values for C/C++ enums for that reason. > > 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. If you are forced to write to a message queue, you will not be able to avoid it. Modern or not, the POSIX interface will be with us a long time. It is even present on some Windows machines (NT/2000) if you want it. > >> 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. Even to temp files? You live a sheltered life. > >> 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. I wasn't talking abuse. On 5 different platforms, the sizeof "ab" could yeild the answers 3,4 or 8, depending upon the platforms chosen ;-) This is not a very good result for such a simple compiler request. > > 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) OK, but go to comp.lang.ada to get the rest. I'm not going to repeat it all here. Sheesh. ;-) -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg