From: dramirez@cs.uml.edu (Dr Amirez)
Subject: Re: Ada --> C Translation, was: Win CE target
Date: 1998/10/11
Date: 1998-10-12T01:17:24+00:00 [thread overview]
Message-ID: <6vrlb4$jj$1@jupiter.cs.uml.edu> (raw)
In-Reply-To: dale-1110981647250001@dale.ppp.cs.rmit.edu.au
In article <dale-1110981647250001@dale.ppp.cs.rmit.edu.au> 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
next prev parent reply other threads:[~1998-10-11 0:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-09-20 0:00 Win CE target William A Whitaker
1998-09-20 0:00 ` Tucker Taft
1998-09-21 0:00 ` dennison
1998-09-21 0:00 ` dewarr
1998-09-28 0:00 ` Ada --> C Translation, was: " Stefan Helfert
1998-09-29 0:00 ` Tucker Taft
1998-09-30 0:00 ` dewarr
1998-09-29 0:00 ` Robert A Duff
1998-10-10 0:00 ` Dr Amirez
1998-10-11 0:00 ` Dale Stanbrough
1998-10-10 0:00 ` Dr Amirez
1998-10-11 0:00 ` Dale Stanbrough
1998-10-11 0:00 ` Dr Amirez [this message]
1998-10-12 0:00 ` Niklas Holsti
1998-10-12 0:00 ` Larry Kilgallen
1998-10-13 0:00 ` dennison
1998-10-12 0:00 ` dennison
1998-10-12 0:00 ` Larry Kilgallen
1998-10-14 0:00 ` dewarr
1998-10-14 0:00 ` Andi Kleen
1998-10-12 0:00 ` PC
1998-10-12 0:00 ` Operating System in Ada (was Ada --> C Translation) Larry Kilgallen
1998-10-12 0:00 ` Tom Moran
1998-10-12 0:00 ` Brian Rogoff
1998-10-13 0:00 ` dennison
1998-10-13 0:00 ` Brian Rogoff
1998-10-13 0:00 ` Tucker Taft
1998-10-12 0:00 ` Chris Morgan
1998-10-13 0:00 ` Dale Stanbrough
1998-10-13 0:00 ` Larry Kilgallen
1998-10-14 0:00 ` dewarr
1998-10-12 0:00 ` dennison
1998-10-21 0:00 ` Van Snyder
1998-10-22 0:00 ` Tom Moran
1998-10-13 0:00 ` Ada --> C Translation, was: Win CE target Robert I. Eachus
1998-10-14 0:00 ` Samuel Mize
1998-10-16 0:00 ` Tasking/blocking system calls (was: Ada --> C Translation) Mats Weber
1998-09-20 0:00 ` Win CE target dewarr
1998-09-20 0:00 ` dewarr
1998-09-23 0:00 ` falis
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox