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

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

[Russ Cox]

> No, that choice pretty much forced the existence of an APE.
> If the standard extern interfaces had been honored, Plan 9
> C could support both the native Plan 9 way of doing things
> *and* Standard C, without requiring any flags etc.

This is just bogus.  The whole point of Plan 9 is that
everything has been rethought.  What forced the existence
of an APE was the desire to compile and run some large legacy programs
without infecting the rest of the system with external
garbage.  Changing the definition of main to return int
would not eliminate the benefits of an APE any more than
anarchy would eliminate the benefits of prisons.

Russ

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

[Dan Cross]

In article <20010426194237.43F56199DC@mail.cse.psu.edu> you write:
>> No, that choice pretty much forced the existence of an APE.
>> If the standard extern interfaces had been honored, Plan 9
>> C could support both the native Plan 9 way of doing things
>> *and* Standard C, without requiring any flags etc.
>
>This is just bogus.  The whole point of Plan 9 is that
>everything has been rethought.  What forced the existence
>of an APE was the desire to compile and run some large legacy programs
>without infecting the rest of the system with external
>garbage.  Changing the definition of main to return int
>would not eliminate the benefits of an APE any more than
>anarchy would eliminate the benefits of prisons.

Interesting perspective (all, including Doug's on Plan 9, yours on Plan
9, and yours on prisons :-).  I think that Doug's point is valid,
though:  the APE, or perhaps more specifically pcc, is the ``mode bit''
of Plan 9.  The idea of having ``another'' main() is also completely
valid, and indeed, quite intriguing.

BUT, your point is valid as well; the APE is a crutch to get some
useful programs to run under Plan 9 with minimal effort, and legacy
compatability must still be provided through a set of libraries.

My suspicion is that it wasn't considered worth the effort to try and
find a `better' solution than the APE as it stands now.  It probably
isn't.  Besides, as Russ implies, one doesn't necessarily want to
allow smooth integration of Unix compatability into Plan 9, in order
to facilitate a clean break with the past.  (Can we now say that the
best way to get over an operating system is to get a new, completely
different operating system?  :-)

	- Dan C.

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

[Boyd Roberts]

From: "Russ Cox" <rsc@plan9.bell-labs.com>>
> This is just bogus.  The whole point of Plan 9 is that
> everything has been rethought.  ...

yup

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

[Douglas A. Gwyn]

Russ Cox wrote:
> > No, that choice pretty much forced the existence of an APE.
> > If the standard extern interfaces had been honored, Plan 9
> > C could support both the native Plan 9 way of doing things
> > *and* Standard C, without requiring any flags etc.
> This is just bogus.  The whole point of Plan 9 is that
> everything has been rethought.  What forced the existence
> of an APE was the desire to compile and run some large legacy programs
> without infecting the rest of the system with external
> garbage.  Changing the definition of main to return int
> would not eliminate the benefits of an APE any more than
> anarchy would eliminate the benefits of prisons.

Look, nobody appreciates elegance more than I do, but there
is nothing intrinsic in the Plan 9 native C environment that
required any incompatibility with Standard C even if there
had never been an APE.  Non-native headers have no effect
if they're not included; the interface to main() is not an
issue if Plan 9 had not insisted on using the same name for
an incompatible function.  This could still be fixed fairly
easily, along the lines I indicated previously.

It is *not* true that in Plan 9 "everything has been
rethought".  Considerable effort was expended to make Plan
9 C (Ken's C) compatible with the C standard insofar as the
"language" part goes, with the notable exception of main().
Compatibility with the "library" part would have merely
required staying out of its way.

The idea that unused headers and unused library functions
would somehow "infect" a system is irrational.

[9fans] purpose of APE

[Howard Trickey]

It is interesting to me that the "purpose of APE" has become to allow
compiling legacy and external programs.  When Andrew Hume and I made APE
originally, the purpose was different.  It was a time when some of the
researchers in our center were actively maintaining Research Unix, while
others were doing Plan 9, and many of us had reasons to work on both
systems.  APE was a viewed as a way of writing the programs we cared about
so that they could be compiled with no change on all of the systems in our
center.  Now clearly, APE on Unix was easy to do and a first class way of
writing programs, while on Plan 9, the mapping is sometimes a bit tortured
(especially signals, select(), and some of the permission stuff), so APE on
Plan 9 is a hack, but it did serve its purpose.

I agree that the current use of APE is indeed to compile legacy and external
programs. But if that were the original goal, it would have been different:
there would have been a more kitchen-sink-union-all-the-Unixes feel to it
(ugly, ugly) so that monstrosities like autoconf would work (and it would
have infected Plan 9 --- especially the system directory conventions ---
more than any of us would have liked).

- Howard Trickey
howard@research.bell-labs.com