Re: RISC

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Sounds reasonable to me. I'd assume that the minute the standard says
"erroneous" I could safely expect that the compiler might make monkeys fly
from my serial port and this would be "legal" behavior. Hence I'd have to
"Boldly Go Where No Man Has Gone Before" and figure out what behavior I get
from *my* specific compiler in *my* environment and decide how far to trust
it.

I don't believe that every program has to be 100% portable, safe or
bug-free. If I *know* I'm stepping outside the bounds of normally acceptable
programmer conduct and totally beyond the walls of any LRM/ARM protection
rules, then from that point on, I'm working closely with my compiler
documentation, the vendor, the assembly output, etc., and isolating that to
some narrow part of the system. Overlays would fall in that category - they
ought to be sufficiently painful to remind you that what you are doing is
dangerous, but should remain possible in an implementation dependent manner.
(There really aren't many excuses for it - but there are a few...:-)

In other words: Never get out of the boat. Not unless you're ready to go all
the way.


MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wcck85koyz5.fsf@world.std.com...
> Erroneous means that, but it also means that your program can do
> absolutely anything, including wipe out your disk or (much worse) work
> properly until you port it or turn on the optimizer or upgrade your
> compiler.
>
> The "erroneous" rule about overlays was removed from Ada 95 quite
> deliberately, because it was recognized that there are (rare)
> circumstances where it makes sense to use overlays.  And because we
> weren't entirely sure what "overlay" means in a formal sense.
>
> Most of the remaining rules about "erroneous" are there for good reason:
> eg, an optimizing compiler really might do something very surprising,
> causing subtle bugs that occur only rarely.
>
> And note that rare bugs are the ones that matter.  A bug that occurs the
> first time you run the program will be found right away, and fixed.  A
> rare bug might escape to customers.
>
> - Bob