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: Niklas Holsti Subject: Re: Ada --> C Translation, was: Win CE target Date: 1998/10/12 Message-ID: <36224936.285E1958@icon.fi>#1/1 X-Deja-AN: 400341840 Content-Transfer-Encoding: 7bit References: <6vp23h$hc3$1@jupiter.cs.uml.edu> <6vrlb4$jj$1@jupiter.cs.uml.edu> Content-Type: text/plain; charset=us-ascii Organization: Space Systems Finland Ltd Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-12T00:00:00+00:00 List-Id: Dr Amirez wrote: > [ snipped a lot of quotes ] > i would have dropped this. But since I am so bored I might as > well flame away. Hoping to entertain you, I reply. > Well the reason why I brought the Operating systems issue up > is that it's impossible to write Ada utilities without an > Ada OS. That is untrue. All Ada systems have the ability to interface to the operating system. For one thing, Ada bindings to the POSIX APIs are extensively standardised. Also, I get the impression that you believe that no Ada OS exists. To my knowledge, at least two OSes have been written in Ada: the OS for the Rational R1000, and the OS for the Nokia MPS-10. (Neither machine is alive today, but this is not because of the OS implementation language.) In addition, many if not most of the run-time systems (real-time kernels) delivered with Ada compilers are written in Ada. > 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. Of course the problem was not that a "core" was left behind. (Having a core dump is indeed better than not having one.) The problem was that the program crashed, instead of giving a helpful error message. > 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. Programs have flaws. Some languages (Ada among them) check for common errors (at compile time and at run time) so that a somewhat meaningful error message can be emitted. Some languages (Ada and C++ among them) let you, the programmer, define what to do when an error is detected at run time. In some cases, the program can recover and continue; in all cases, it can issue a detailed, specific error message that helps you fix the flaw. The C language just runs on until the program is totally messed up. Want to bet in which language bugs are easier to fix? [ examples of C problems snipped ] > 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. You are exaggerating this. What can happen is that either just this task blocks and the other tasks continue, or all tasks block until the I/O completes. The latter (undesirable) behaviour can occur in an Ada implementation under an OS such as Unix or Windows NT, if the entire Ada program has been mapped to one OS process and the I/O call is process-blocking. Exactly the same two cases can occur in a multi-threaded C program, depending on the type of threads and OS calls used. In modern Ada implementations the usual approach is to make each Ada task a thread and use I/O calls that block only the calling thread. Whichever case happens, the execution of the Ada program continues, once the I/O is completed. Only the real-time aspects are affected. Note that Ada was originally intended for bare embedded systems where this problem cannot occur. The idea was that the whole system, including I/O drivers, is written in Ada using the Ada tasking model and run-time system. In this context, the Ada standard defines the intended real-time performance quite clearly. Modern Ada implementations using threads also do this well. > 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? The attitude is to check the compiler documentation for the blocking implications of OS interactions -- if you are using an OS. Again, this affects only real-time performance. In practice, the only case where this problem is significant for portability is where some task is waiting for an I/O that can take an indefinite time, such as reading an operator command or a network message. If your program needs this, you choose a non-blocking OS call, or check that your compiler uses such calls for Ada I/O procedures. > 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. " The C problems are in C itself. The Ada task blocking problem is not in Ada, but in the Ada-OS interaction. I've met many C programmers who use the "try it and see" approach. Also some Ada programmers... but it is definitely not the "Ada attitude". > Dr Amirez Niklas Holsti