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-Thread: 103376,c1da643bcd91f37b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news4.google.com!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Advice on low level file handling. From: "Peter C. Chapin" References: Organization: Kelsey Mountain Software Message-ID: User-Agent: Xnews/5.04.25 Date: 05 Apr 2006 10:41:13 GMT NNTP-Posting-Host: bfcf64fb.news.sover.net X-Trace: DXC=1[gDboY_DmDjJkYWB:3Q7LK6_LM2JZB_C5VZaBdb5Y0L:WUUlR<856OlK1^P;l9TFFlTS^iITk_1D X-Complaints-To: abuse@sover.net Xref: g2news1.google.com comp.lang.ada:3726 Date: 2006-04-05T10:41:13+00:00 List-Id: "Randy Brukardt" wrote in news:R_adnVLVrp7jUazZRVn-rw@megapath.net: > Why aren't you using Stream_IO for this? You don't need to declare > your own types for this sort of I/O. Perhaps you thought that you > could only use Stream_IO with the stream attributes? Actually, I think > it is more useful to use by itself, especially in the sort of case you > have here. Byte at a time I/O can be painfully slow; Stream_IO lets > you input a batch of stuff and then process it. I see. Thanks for the suggestion; I'll take a look at it. > OTOH, if you *must* have an 8-bit byte, then I'd suggest declaring it > yourself and using Sequential_IO as you did. Well, the RFC is described in terms of 8-bit bytes so using anything else will result in an unclear correspondence between the code and the specification. At least, that would be my expectation. On the other hand, it might make sense to define a suitable record type that has the necessary fields already specified in the right places and then just read a chunk of the file into such a record. However, part of the file needs to be uninterpreted data---it's not a file of records--- so this approach may not work out well either. > Not really, but an Ada compiler will reject the program if it doesn't > work. (As someone else pointed out, many Ada compilers don't support > 64-bit numbers.) But it's probably portable enough for your purposes; > there isn't much point in working around the lack of 64-bit math until > you actually have to work on a compiler that doesn't support it. I can see why the C99 standard added a 64 bit type to the standard. In today's world, objects larger than 2/4 GBytes are not unusual. It's awkward talking about such large sizes without a standard type to represent them. Does Ada 2005 have a built-in type that is 64 bits (or more)? Peter