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: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-08 16:48:54 PST Path: archiver1.google.com!news2.google.com!newsfeed.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!howland.erols.net!portc.blue.aol.com.MISMATCH!portc01.blue.aol.com!uunet!dca.uu.net!ash.uu.net!spool1.news.uu.net!spool0.news.uu.net!reader0.news.uu.net!not-for-mail Sender: DB3L@CTWD0143 Newsgroups: comp.lang.ada 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> <3B70C665.BBC5F000@home.com> From: David Bolen Date: 08 Aug 2001 19:49:19 -0400 Message-ID: Organization: Fitlinxx, Inc. - Stamford, CT X-Newsreader: Gnus v5.7/Emacs 20.6 NNTP-Posting-Host: 208.247.212.3 X-Trace: reader0.news.uu.net 997314528 27283 208.247.212.3 Xref: archiver1.google.com comp.lang.ada:11653 Date: 2001-08-08T19:49:19-04:00 List-Id: "Warren W. Gay VE3WWG" writes: (The end of the post does answer my question, so feel free to skip to there to avoid some intermediate discussion :-)) > Are you suggesting that every binary file that you've ever done I/O > on, is don'e in a perfectly portable fashion? Really? I rather > doubt it, because I've seen a lot of code in the form of Open > Sourced projects that do just that. Well, I'm not sure what "a lot of code" in open source projects necessarily has to do with assumptions about my own code. To answer your question, yes, that's how I do it. Virtually all of my development for the past decade+ has been networking and I'm rarely involved in a homogenous environment (systems, tools, etc...), so as it happens portability is ingrained in everything I do. In fact, that's also why I prefer non-binary formats whenever possible (unless pre-supplied portable or standards-compliant marshallers are already available). I find that the portability afforded by textual formats is generally an easy trade-off for any efficiency loss. But that's really an aside unrelated to the question I was asking. I wasn't looking to justify why you would take one approach over the other, but just looking for information about how Ada handles structure I/O. > For example, if you were to write cpio, excluding the portable format > (-c), are you not going to write the binary header out directly? > Sure you are. You don't have to of course, but this is different > from general experience. I'm not sure if you mean writing the full binary header as a structure in one shot, or just writing binary data in the header. I'd have less of a problem with the latter than the former - although doing the former does get to my question about Ada's structures, e.g., consistency of packing, compatibility across platforms and compilers. In my case, when I do use binary data/headers, I ensure that I stamp them with the endian-ness in which they were written. This yields best performance in the native environment, but permits portability. This is the same approach, for example, that the bsddb library takes for its meta data. Note that cpio is a good example because only the oldest (declared obsolete, albeit often still the default) formats used a binary header. All of the recent formats have been portable, and in fact, often the headers are in ASCII. And at a minimum, on reading, the binary format has magic values in it that permits detection of endian-ness. It's awfully rare to have an archive format (whether it be tar, zip, or whatever) that doesn't take portability into account. > EVEN IF YOU IGNORE FILEs, you don't have portability concerns when > you write to pipes, UNIX sockets (ie. local to the same host), > call msgsnd() and msgrcv() for message queues. These do not require > any endian issues because you're talking to processes within the > same host. It would simply be a _waste_ to write to your > process on the same host, in an endian neutral way (depending > upon the endian orientation). This shifts to an endian focus when that was really only part of my original question. I may not have endian concerns with local I/O but I could certainly have larger structure alignment concerns between two communicating applications. In the Ada case, would writing a structure to one of those constructs then be readable (as a complete structure) from the other end with code written with another Ada compiler from a different vendor? > In all of these cases, you'll want to know what the "real" > length is. Of course, you could take the "I don't care about a > byte or two of extra waste", and depending upon the situation, > I might agree. I only point out, that in C/C++, that these > issues do arise in practical situations. Yes, but the "real" length you want to know for the purpose of the I/O is "on the wire", and not necessarily in-memory. Of course, you might want to know both lengths, but it's the wire length that matters for the communication I/O. And wire length versus memory length may not be the same, so you don't necessarily want to base the former on a query of the latter. > > Does Ada support simply performing I/O on such structures to > > constructs as files, sockets or message queues in a portable way > > (without explicit marshalling), such that some other Ada application > > (even with a different compiler and/or platform) would receive the > > structure intact? > > It can, as can C++. But not out of the box. In Ada, you can > define how the object is read or written. Ada's streams work > differently than C++'s streams, but the ideas are similar. > > There is however, another "distributed systems annex?", to > which I must confess ignorance of > at the moment (I have not yet tried it), that does the equivalence > of RPC (or at least I think GNAT does it this way). > > Now I am not certain of this point, but it is _likely_, though > probably not guaranteed, that XDR formats will be used for this > (big endian format, portable etc.) But please don't quote me on > this, since this particular answer is entirely _wild_ _speculation_ > on my part. Someone with more Ada experience can help us out on > this point, if they are willing. Thanks - that's really what my question was aimed at. While having such an XDR (or XDR-like) definition in an Annex would bring that into the Ada specification, it sounds like handling this with Ada is pretty close to how its handled in other situations. -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/