[comp.arch] Bad Code

forrest@blia.UUCP (02/26/87)

My opinion of this is that it shouldn't be thought of catering
to bad code but instead as an excellent way of finding bad code.

I work in a group that produces software for many environments.
The code is developed on Unix. Since I'm in charge of VMS software,
I have to port it to VMS. You'd be amazed at the number of bugs
that I've found due to the fact that VMS protect the first page
of memory.

(Note: this is not meant to be a Unix vs. VMS posting. Unix could
also protect the first page and still be Unix.)

Jon Forrest
ucbvax!mtxinu!blia!forrest

res@ihlpl.UUCP (03/02/87)

In response to:

> My opinion of this is that it shouldn't be thought of catering
> to bad code but instead as an excellent way of finding bad code.
> 
> You'd be amazed at the number of bugs
> that I've found due to the fact that VMS protect the first page
> of memory.

When I was involved in developing a large logic simulator written in C
on the IBM TSS/370 system, we routinely set a TRAP on stores into the
first 256 bytes of the virtual memory address spectrum.  It was
amazing, the number of stores done through uninitialized pointers!
Fortunately, the trap indicated where in the many kilobytes the stores
were being done, so debugging was greatly facilitated by this feature.

This was one of many features which "contemporary" operating systems
still lack, as bad-mouthed as TSS was.

					Rich Strebendt
					...!ihnp4!iwsl6!res