Re: [9fans] the declaration of main()

[forsyth@caldo.demon.co.uk]

>>fashion.  He has a point, and indeed, someone today ran into problems
>>trying to mix `native' Plan 9 functions with functions taken from the
>>APE.  (Sorry, I didn't pay close enough attention to see who it was!)

>>True, one cannot easily mix and
>>match `native' Plan 9 and APE functions, but I think that might be a
>>good thing.

That was possibly bound to happen, not so much because of ANSI C but
because of all those Unix system calls.  You've got to implement them
somehow.  You've therefore got a choice: in the kernel or not.  To
mimic more precisely the effects or side-effects of Unix system calls,
or implement them at all (eg, select) the real Plan 9 system call is
called something else in the APE libraries (eg, _READ) and the name
`read' invokes something that maintains lots of state for `select' and
emulate some other aspects of Unix more accurately.

I don't want that cost in native Plan 9 programs.  I know, I know,
they could have used `p9read' or `sys_read' instead and avoided the
main POSIX names and then you could use both (but what about SPEC1132
or whatever it was -- people just get too carried away sometimes).

Even if they did all that, they'd unfortunately still need to specify
how the two sets of system calls interacted.  It's bad enough
implementing it in the first place.  See
/sys/src/ape/lib/ap/plan9/buf.prom for a Promela model of APE
select/read.  I found that interesting because when i wrote my own
operating system for 386 and Sun about 8 or 9 years ago,
select/read/write was the one thing i used Spin to model because the
definition was fiddly and I got it wrong the first time.
I also had to write a great MANY #include files.  There's a little joke
that the wc -l of the #include files for most Unix systems (esp. Linux)
is bigger than the source code of the Plan 9 kernels; and they're less readable.