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,24d7acf9b853aac8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Mon, 9 Aug 2010 19:51:04 -0500 Organization: Jacob Sparre Andersen Message-ID: References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <1qk2k63kzh7yv$.3jgc403xcqdw$.dlg@40tude.net> <8ae8e899-9eef-4c8c-982e-bfdfc10072f1@h17g2000pri.googlegroups.com> <258zlxrv4fn6.1vszho1rtmf48$.dlg@40tude.net> <984db477-973c-4a66-9bf6-e5348c9b95f2@n19g2000prf.googlegroups.com> <46866b8yq8nn$.151lqiwa0y2k6.dlg@40tude.net> <13b07f2c-2f35-43e0-83c5-1b572c65d323@y11g2000yqm.googlegroups.com> <13tpf7ya3evig$.h05p3x08059s$.dlg@40tude.net> <1lhdkikeh2sif.bd3pon3knbv8.dlg@40tude.net> <7027f0c6-d909-428c-ab8d-6ba1bd7ff4b2@x21g2000yqa.googlegroups.com> <1424bzz54867w.soj1iq72wkwl$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1281401466 29523 69.95.181.76 (10 Aug 2010 00:51:06 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 10 Aug 2010 00:51:06 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:13028 Date: 2010-08-09T19:51:04-05:00 List-Id: "Robert A Duff" wrote in message news:wccbp9bspzy.fsf@shell01.TheWorld.com... > Simon Wright writes: > >> Natacha Kerensikova writes: >> >>> and I don't know either how to deal with cases where Stream_Element is >>> not an octet. >> >> By ignoring them, I think! > > Are there any such cases in the real world? There are machines > in the embedded world where Storage_Element is not 8 bits. Not sure if it still exists in the real world, but the compiler we did for the Unisys mainframes used Stream_Element'Size = 9. (The Unisys mainframes are 36-bit machines.) Stream_Element'Size = 8 would have made the code for handling arrays awful. Similarly, Character'Size = 9 on that machine. While the upper bit was not used in the representation, this is surely not an Octet. > But any machine that's hooked up to any sort of network > is going to be talking Octets, I think. Does anybody know of > counterexamples? The network interfaces on the Unisys machines required binary or text mode settings: in text mode, the extra bit was just dropped; in binary mode all of the bits were sent (not sure precisely how that was done, it was in the OS). > Perhaps Stream_Element should have been defined as exactly > 8 bits. Perhaps it should have been called "Octet". That would have made a compiler for the Unisys machines impossible; it would have made streaming impossible. There is no sane way to put 36-bit values into Octets - the only way that would have worked would have been to use 16-bits for every 9-bit byte. Whether this is a significant consideration today (in 2010) is debatable, but it surely was a real consideration back in 1993-4. So Ada 95 could not have made this choice. Randy.