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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6353697ffeb79d16 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 18 Nov 2010 12:22:53 -0600 Date: Thu, 18 Nov 2010 13:21:57 -0500 From: "Peter C. Chapin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Encapsulating Ada.Direct_IO References: <5ba4147a-6099-4a05-b548-09544f58247a@j18g2000yqd.googlegroups.com> <162dnSHurcNcEHnRRVn_vwA@giganews.com> <2edbda42-28e8-462c-9005-eda66538274b@p11g2000vbn.googlegroups.com> In-Reply-To: <2edbda42-28e8-462c-9005-eda66538274b@p11g2000vbn.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-4C4KRVNWi6xb2s6AbCx5vLoILQDrYuD32kJ81bPhU6dwIm7YFLBp6zH6RgRqURSdU9ejZdylfkyyc2X!zWxvJ1WYoRIixK9bI1Ot78pfIkIXICWPIP3jviDWmdyFNgYkxesEOiQ3U+F52qk= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3477 Xref: g2news2.google.com comp.lang.ada:16563 Date: 2010-11-18T13:21:57-05:00 List-Id: On 2010-11-18 11:36, Adam Beneschan wrote: > I have a longish rant that touches on this, but the short answer is > that I don't think there's an Ada answer to your question. If you had > a file defined as using 8-bit units, and that file got put onto a > system that uses 36-bit words, you'd need to know just what the OS is > going to do with it, and how the particular Ada implementation will > deal with files on that OS. It may be that the native "read from > file" service on that OS will put each byte into a 9-bit byte and zero > the high bit. I don't see how to avoid implementation-dependent code > in a case like this. I understand what you are saying but it is less than satisfying. :) I'm thinking about the very common case when one is trying to read a file that has a format defined by some third party. For example the specification of the format might say, "The first octet of the header defines the message type and can be one of the following values... The type field is followed by a 24 bit length field in big endian form. The body of the message follows the length field, and finally a 32 bit CRC follows the message body." I want to write an Ada program that can read in a file like this and process it. Are you saying that it's impossible to write such a program in a portable manner? What I've been doing is as I showed earlier... define my own "Byte" type with Byte'Size set to 8 and the instantiate Sequential_IO. My program then interprets the individual bytes as necessary. It seems to work with GNAT. I suppose that C has the same issue, really. The C standard does not promise that char is exactly 8 bits. If it isn't I'm not sure what happens when you do int Ch; while ((Ch = fgetc(infile)) != EOF ) { ... } I guess that's the same point you are making. Maybe the C standard talks about this issue. Checking... I just took a quick look at C99's description of fgetc and it says, "the fgetc function returns the next character from the input stream." That seems to beg the question, doesn't it? Peter