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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.131.6 with SMTP id v6mr244877qas.1.1386758100567; Wed, 11 Dec 2013 02:35:00 -0800 (PST) X-Received: by 10.182.113.194 with SMTP id ja2mr5239obb.31.1386758100513; Wed, 11 Dec 2013 02:35:00 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!p15no18817172qaj.0!news-out.google.com!p7ni14989qat.0!nntp.google.com!p15no18817171qaj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 11 Dec 2013 02:35:00 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=109.149.1.116; posting-account=pmkN8QoAAAAtIhXRUfydb0SCISnwaeyg NNTP-Posting-Host: 109.149.1.116 References: <1d445f04-b670-444f-9858-55da271fe17a@googlegroups.com> <2b6dc37f-4aa6-4c18-be59-8c09f6f37f01@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <87776124-a842-4b29-a094-e78a54cb7d49@googlegroups.com> Subject: Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking. From: Austin Obyrne Injection-Date: Wed, 11 Dec 2013 10:35:00 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5759 X-Received-Body-CRC: 2500930165 Xref: news.eternal-september.org comp.lang.ada:17945 Date: 2013-12-11T02:35:00-08:00 List-Id: On Tuesday, December 10, 2013 9:49:36 PM UTC, Randy Brukardt wrote: > "Aust= in Obyrne" wrote in message news:2b6dc37f-4aa6-= 4c18-be59-8c09f6f37f01@googlegroups.com... On Tuesday, December 10, 2013 6:= 37:28 AM UTC, Randy Brukardt wrote: ... >Please consider this procedure in = the program that gave trouble, > >This is the defacto stripped down procedu= re > >EXIT when EOF; > EXIT when EOL; > > FOR I IN 1 .. 3 LOOP > Ada.Intege= r_Text_IO.Get(File =3D> InData, Item =3D> W(I)); > --Ada.Integer_Text_IO.Pu= t(Item =3D> W(I), Width =3D> 8); > END LOOP; > >LOOP; >LOOP; I presume that= there is a New_Line in there somewhere so that the line endings aren't los= t completely. But this isn't going to work, as Get for a character is defin= ed as follows: "After skipping any line terminators and any page terminator= s, reads the next character from the specified input file and returns the v= alue of this character in the out parameter Item." So if you have any line = endings in between the 1st and 2nd characters (or between the 2nd and 3rd c= haracters), you'll end up ignoring them. I doubt that's what you want. (Ada= abstracts the line, page, and file terminators so you don't have to worry = about how they're represented. The problem being that you *can't* see how t= hey're represented if you are using Text_IO.) Using Text_IO without losing = line endings and the like is tricky. I generally don't bother, just reading= a line at a time with Get_Line and then process whatever I get. (And I jus= t ignore page terminators, which are rarely used anyway.) But if I was writ= ing this sort of code, I wouldn't worry about line endings at all, and simp= ly encrypt the file as binary data, using Stream_IO to read it in and out. = Randy. Hi Randy, I am not in that league of theoretical Ada that I can debate wit= h any of you guys. For your info there are lots of New_Lines in the sample = I submitted but I think there are other instances where there may be only o= ne. My Ada programs have NEVER failed in thousands of runs - in fact they h= ave never failed for any language syntax reason in about 10 years!. I am ta= king on board what you say is a definition of GET for pondering later. Can = I tell you where I am coming from, Forget about programming my ciphers in t= he Ada language or any language. The cryptographic strength of the cipher d= epends on the veracity of the mathematical proof of the cipher algorithm al= one. That in my case is written in stone. Demonstrating the cipher in Ada i= s the language I happen to greatly favour because of the workmanlike transp= arency of this langauge but the fact of my using gnat 311.p is merely a tok= en and other updated gnat evrsions will always need to tested like right no= w 2013 version of MAC. Fundamentally, the crypto strength is both insured a= nd assured beforehand regardless of how it runs in programs and if it fails= for programmimg language reasons that is something that can be fixed and i= t is not as serious as being broken by cryptanalysis.=20 I am of the belief there are always going to be problems to be expected whe= n changing platforms like this. Up to now the programs to hand are very, ve= ry solid and even surprise me at the things they seem to shake off like enc= rypting source code so accurately where the smallest lack of fidelity could= cause it to not run later on the decrypted sourcecode. I think that in the= future each implementation on whatever platform is going to need tweaking = initially but once that is done the natural stability of Ada will take over= thereafter and when the cipher is wrtten it is there for all time.=20 *It is hugely important for me to establish the fact that the cryptographic= strength of my ciphers is ring-fenced independently of any langauge and ma= y even be done in longhand fashion of push came to shove. The class of these ciphers is demonstrably the ultimate clas of "Theoretica= lly Unbreakable" and must not be undermined ever by whatever language is us= ed - that is merely a conveyance - achieving cryptographic of perfect secer= cy is so difficult it is almost like a Greek Classic. adacrypt.