Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!unc!steele
From: steele@unc.cs.unc.edu (Oliver Steele)
Newsgroups: comp.sys.mac
Subject: Re: Possible LSC improvements
Message-ID: <1612@unc.cs.unc.edu>
Date: Tue, 13-Oct-87 23:01:06 EDT
Article-I.D.: unc.1612
Posted: Tue Oct 13 23:01:06 1987
Date-Received: Thu, 15-Oct-87 06:43:35 EDT
References: <2071@sfsup.UUCP| <170026@acf3.NYU.EDU>
Reply-To: steele@unc.UUCP (Oliver Steele)
Organization: University of North Carolina, Chapel Hill
Lines: 69

singer@endor.UUCP (Richard Siegel) writes:
>My personal preference is not to use a cache; crashing doesn't worry me
>because I always save my source files before I run. What worries me is
>that a bad pointer could possibly corrupt the cache without crashing the
>machine, and cause garbage to be written out to disk when the cache is flushed.
>I don't know if that's a valid worry, but I prefer not to use the cache.

It is a valid worry, but only if the cache is unflushed when the rogue
program writes into it.  If LSC does a FlushVol before it runs a project,
and it sounds like it does from the grinding it makes on a floppy, then
the worst a rogue can do is fill the cache with random data which gets
written over again anyway.  Well, the worst it can do is mess up the
directory for the cache so that the caching code thinks it needs to be
flushed again and messes up your disk after all, but this is pretty hard
to do and a rogue can always misfire into the memory mapped i/o or
accidentally call the Sony driver anyway.

>The user can tell if the cache is turned on, and I suppose LightspeedC
>could detect whether it's turned on, but it's impossible to know *where*
>above BufPtr the cache is. Very often the cache isn't the only thing in 
>high memory.

TN81 tells how to turn it off, but it says that this is probably best
left under user control and this sounds like a good idea.

As far as LSC improvements, I would like to see:

o   Allow function declarations in prototype form, i.e.
	static void foo(int a, long *b)
	{
		...
	}

o   Allow a function declaration to server as a prototype, i.e.
	static void bar(long l){...}
	main{ bar(123); /* gets coerced */}

o   Make 'pascal' a modifier with its own flavor, instead of a storage
    modifier, so I can say
	static int pascal xyzzy();
    (this isn't very important, but it bothers my gestalt).

o   Allow the use of PC-relative addressing for globals within a
    code segment.  Sure it's non-reentrant, but writing fancy INITs
    or code that installs itself as a permanant patch is very painful
    right now.

o   Maybe give users a way to have smaller default windows on a large
    screen.  It's nice to be able to see more code, but it's also nice
    to be able to see more windows at once without having to resize
    them all first.

Was it Alan Kay or Larry Tessler who said the Mac is the first computer
worth criticizing?  Lightspeed C is the first C worth nitpicking.  My
non-nit:

oo  How about Lightspeed C++?  With MacApp, and a Browser written in C++,
    and an extensive class library, and... well, I'll settle for LSC++.
    Heck, I'll "settle" for LSC3.0, but I'll perform man-years of hard
    physical labor (this does translate into $$, but I'm not a real good
    physical laborer so it's not as much as it sounds) for LSC++.  Please?


------------------------------------------------------------------------------
Oliver Steele				  ...!{decvax,ihnp4}!mcnc!unc!steele
							steele%unc@mcnc.org

	"'As it were' means 'I think that I sound very erudite.'
	 'Per se' is Latin for 'as it were.'  As it were."