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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ded6ba3fc5b87b66 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: First time Ada has let me down Date: 2000/10/25 Message-ID: #1/1 X-Deja-AN: 685647140 References: <8FD7DEBEEsynoptikdamudderfuck@news> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 972478424 216.215.75.185 (Wed, 25 Oct 2000 07:53:44 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Wed, 25 Oct 2000 07:53:44 CDT Newsgroups: comp.lang.ada Date: 2000-10-25T00:00:00+00:00 List-Id: "Shifty" wrote in message news:8FD7DEBEEsynoptikdamudderfuck@news... > OK, here's the story: > > I had a problem at work where I needed to calculate the offset of a > "magic number" within a buffer containing an IP datagram. > > The magic number is 3 protocol headers deep within the datagram, and > all three headers are variable length. I needed to find the HLEN > fields of the IP and TCP headers in memory. Turns out both of these > are stored in 4 bits. The data in the other 4 bits of the octet > belong to another field in the header. > > This stumped me for awhile, but then I went home and picked up a C book. > Hmmm, chapter 15 - bit fiddling. I learned a bunch of stuff about masks > and bitwise operators and came up with a working solution. (which seems > much better than using record representation clauses and typecasting a 4 > bit value into an 8 bit integer) I'm curious about the "typecasting a 4 bit value into an 8 bit integer" statement. Why would you need to do this? I would have thought the record representation clause approach would be much preferable than a bunch of #DEFINEs to describe the header layout. Granted, the fact that the headers are variable length complicates things a bit, but just looking at an IPv4 header, I would expect something like the source code below. In fact, if you use this approach (records with variant), you might be able to avoid some of the offset calculations altogether. You certainly don't need to do any low-level bit twiddling (which is why this wasn't as big of a deal in Ada83 as you might think...) package IPv4 is type Byte is range 0 .. 16#FF#; for Byte'Size use 8; type Version_Type is range 4 .. 4; subtype Header_Length_Type is Integer range 5 .. 15; subtype Total_Length_Type is Integer range 0 .. 65_535; -- more types for the rest of the header type Option_Type is array (1 .. 4) of Byte; pragma Pack (Option_Type); type Option_Type_Array is array (Integer range <>) of Option_Type; pragma Pack (Option_Type_Array); type Header_Type (IHL : Header_Length_Type) is record Version : Version_Type := 4; Type_of_Service : Byte := 0; Total_Length : Total_Length_Type; -- the rest of the mandatory fields case IHL is when 5 => null; when 6 .. Header_Length_Type'Last => Option : Option_Type_Array(6 .. IHL); end case; end record; -- record rep spec goes here end IPv4; > Next morning I tried to implement the solution and couldn't find the Ada > equivalent of C's bit-wise & operater. According to my "Ada as a 2nd > language" book, the Ada reserved word "AND" only works for boolean types, > not integer types. I got the impression that it was up to the programmer > to write his own bitwise ANDs/ORs/XORs, etc (it wouldn't be hard). > > Luckily I found a vendor-supplied package which provided this > functionality, but I can't believe Ada (83) doesn't have native > language support for these!!! Please tell me that I am hopelessly > confused and dead wrong! > > Cheers, > Andrew.