Date   : Wed, 23 Sep 2009 18:57:09 +0200
From   : rick@... (Rick Murray)
Subject: Beeb, this was your grandma!

Philip Pemberton wrote:

> I actually like having a compiler that doesn't try and protect me from 
> myself...

:-) C's flexibility can be useful and powerful, but it carries with it 
the problem that you must know exactly what you are trying to achieve at 
all times and never have lapses of memory/judgement.
Computers are good at tedious boring things, so bounds checking ought to 
be something the computer does.

If not that (for I can hear Unix weenies screaming in indignation <g>), 
how about a compiler that does all the sanity UNLESS you tell it otherwise.


> Right, let's tear this apart from the inside out...

Don't take too long, I made it up. I did have somewhere an actual RISC 
OS program that was full of horrible incomprehensible assignments, but I 
don't know which computer/disc it is on. For another real example, I'm 
sure the obfuscated C contest would help, but at least they have the 
excuse of doing it on purpose!


> You can play silly games like this:
> (int*)(((int)(&fred))+1)

Yup - that's a good example of something icky.


> data = mydisc->track(5)->sector(8)->data->clone();
> printf("Data byte 5 is %02X\n", data[4]);
>     // array indices are zero-based


extern discdata *disc_readsector(int track, int head, int sector);
...
data = read_sector(5, 0, 8);
printf("Data byte 5 is %02X\n", data[4]);
...


> I'm really not sure how you'd do this in C, but I suspect it would 
> involve something like this:
> 
> DISC_CTX *disc;
> TRACK_CTX *trk;
> SECTOR_CTX *sector;
> 
> disc_GetTracks(disc, &trk);
> track_GetSector(trk, 5, &sector);
> printf("Data byte 5 is %02X\n", sector_GetByte(sector, 4));

Surely you're caching an entire disc in "disc", then a track in "track" 
for it to work?

Why not just a function that, given a CHS location, goes fetch? Doesn't 
need to identically clone what C++ does, just needs to have the same result.


> <this> ===> system libraries / system headers
> "this" ===> application specific headers

Why the distinction?


> I did some tests with Turbo Pascal bounds checking. I seem to recall it 
> slowing down my code by somewhere on the order of 4-6x. This was 
> data-processing code that did a lot of array accesses, though.

Likewise VB with checks vs without. It's a heavy penalty, but maybe if 
this was at least an OPTION rather than self-righteous laziness on a 
power drive, perhaps the conglomeration of the world's software would be 
a LOT tidier and less buggy.


> A lot of C bootstraps (crt0 code) allocate more RAM than necessary for 
> the application's data store, then fill all of it with the value 
> 0xBAADF00D, 0xDEADBEEF or something similar.

Meanwhile quite a few programs allocate more memory than is necessary 
for the strings likely to fit. This caused probs in a news reader when 
the message id string was "longer than the RFC said", but without bounds 
checking - and it failed when somebody posted messages with 
unnecessarily long IDs...

So much use of strxxx() instead of strnxxx() functions, too. Really, the 
compiler ought to have sanitised this!


> UCSD Pascal.

Heh, I knew there'd be something!


 > A complete operating system, Pascal compiler, and so forth.

Well, not quite. A portable p-code interpreter optimised for code that 
is generated by a special pascal compiler. Like a '70s version of Java.
   http://en.wikipedia.org/wiki/UCSD_Pascal

It does run as an operating-system-like package, but it's an interesting 
(in those days) way to do it.


Best wishes,

Rick.

-- 
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...