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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,76da32d8c4934801 X-Google-Attributes: gid103376,public From: dramirez@cs.uml.edu (Dr Amirez) Subject: Re: Ada --> C Translation, was: Win CE target Date: 1998/10/11 Message-ID: <6vrlb4$jj$1@jupiter.cs.uml.edu>#1/1 X-Deja-AN: 400089488 References: <6vp23h$hc3$1@jupiter.cs.uml.edu> X-Complaints-To: abuse@uml.edu X-Trace: ulowell.uml.edu 908155044 22894 129.63.1.6 (12 Oct 1998 01:17:24 GMT) Organization: UMass-Lowell Computer Science NNTP-Posting-Date: 12 Oct 1998 01:17:24 GMT Newsgroups: comp.lang.ada Date: 1998-10-12T01:17:24+00:00 List-Id: In article dale@cs.rmit.edu.au (Dale Stanbrough) writes: >Dr Amirez wrote: > >"Well, any software needs testing. Much of this is the fault of UNIX > vendors. I understand the bugs got reported times after times but > never got fixed. I can only think of one reason: patching one thing > will only make another problem emerge. That's sad. But then the time > for UNIX has passed, investing into fixing UNIX bugs isn't productive. > Then again, how many times does the ACM get a chance to test an OS > in Ada? Theoretically such an OS will be better than UNIX/NT/LINUX, but > you never know." > > >Um, they weren't part of the OS, I was talking about the _Utilities_ such >as vi, cat, etc. that come with it. The article commented on the fact that >these programs had a very long history of no problems, yet were still >vunerable to failure. An Ada program could well have the same faults, >but given the inclusion of array bounds checking, and numerous other >checks these would have either been picked up earlier, or would have >resulted in a constraint_error exception - which I view as being >better than a core dump. At least with a constraint error you can be >reasonably assured that no other data has been corrupted and saved >unwittingly due to a program running on. > >I don't understand why you started talking about OS developement in >Ada. You seem to have a very strange way of making a point. I certainly >don't understand what you are on about. > > >"How about I hate guessing. I will wait for a an Ada OS to come along. > Linux is (used to be anyway ) a one man project. Surely an OS can't be that > hard to build." > >Ok you may hate guessing, but what i asked was a rhetorical question, so >it didn't need an answer. > >"Please leave AT&T out of this. They contribute greatly > to the Computer Sci community. Without them I would still be working > on some obscure system written in a mixture of FORTRAN, PL1 and assembly." > > >Maybe they do, but you were the one who claimed that you can't write >system software with facilities that are system dependent, which is >exactly what AT&T have done. I really don't understand what you are >on about, and I suspect that continuing this discussion is just a waste >of time. > >Good Bye. > >Dale i would have dropped this. But since I am so bored I might as well flame away. Well the reason why I brought the Operating systems issue up is that it's impossible to write Ada utilities without an Ada OS. But if you could build Ada utilities on UNIX that outperform UNIX C utilities then it's fine with me. Make sure you ship copies to the ACM. The core dumping has been a facility on UNIX to assist in debugging .Maybe you don't know enough about UNIX. C programs can disable the core dumping if they want to. The reason a core was left behind was for the debugger to look at. Maybe Ada programs don't have bugs so they don't have to dump cores or they contend with printing a message "Array out of bound" then exit. I feel neither approach is adequate. There are systems out there without a screen to display a message or a disk drives to dump a core. Bugs are bugs. They need to be fixed. I couldn't care less how they are handled. They just need to be fixed. Last, the undefined behaviour of C are pretty well known and well documented. It's unlikely that there is an undefined behaviour that I don't know about: A few examples are: i = i++; /* dont do this. You have been warned */ char *c = "abc"; c[0] = 0; /* don't do this. You have been warnted */ fflush(stdin); /* Don't do this. You have been warned*/ The attitude of C towards undefined behavior is "Don't do it" period. Not knowing Ada, i will have to reiterate on the example of undefined behavior on task. Basically if a task blocks on I/O then anything -absolutely anything -can happen. What is the attitude of Ada? Don't use tasks? Use tasks but do not perform I/O in tasks? Have tasks perform I/O and pray nothing bad happens? Someone here complained about C leaves so many things undefined. True. Just don't do them. It's not "Yeah, it might work for you, try it and see. " Dr Amirez