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.

[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

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.

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

[rob pike]

All right!  All right!  Enough!!!

I am the person who changed the definition of main.  At the time, we
had no plans of being compatible with anyone else's standard system.
On the other hand, we avoided gratuitious incompatibility and we just
plain missed the one for main.

Exit was changed to exits and it was unwise not to do something about
main, but it didn't cross my mind.  The reason is probably that we
were pushing for stronger-than-ANSI C, requiring prototypes, and I
knew we needed to make some changes because a different signature for
exit would cause trouble to existing programs (we changed creat to
create when we added the third argument, too) but I unconsciously knew
that the prototype of main wasn't in the headers and so I bet it just
never crossed my mind to change it.

Now please let that be the end of this discussion.  This group
deserves a higher signal to noise ratio.

-rob

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

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]

i MEANT, for the implementation of all that Unix/POSIX/STDwhateveritis
that some seem to think is required.


[-- Attachment #2: Type: message/rfc822, Size: 1834 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] the declaration of main()
Date: Mon, 30 Apr 2001 09:24:51 GMT
Message-ID: <3AEB4458.A948080D@null.net>

forsyth@caldo.demon.co.uk wrote:
> working code reaches those parts that whinges will not reach.

I already posted working code.

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

[forsyth]

>>could we please end this?

i suggest that if an individual or group thinks they can produce
a better implementation of these things for Plan 9 that will
solve everyone's problems they set out and do it and let the list know when it's done.
working code reaches those parts that whinges will not reach.

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

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> working code reaches those parts that whinges will not reach.

I already posted working code.

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

[forsyth]

>>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.

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

[Dan Cross]

In article <20010428180016.D91AC199ED@mail.cse.psu.edu> you write:
>
>  [...]
>

Oops, sorry, I should have used better grammar.  :-)  By saying, ``I
think that might be a good thing,'' I meant, ``it's a good thing that
you cannot mix and match between Plan 9 and the APE.''

Doing so is fraught with the problems which Charles and others have
mentioned, *plus* leads to programs which aren't really portable back
to Unix/POSIX.  In that respect, it's better to keep them seperate.

	- Dan C.

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

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> 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 ...

What this points out is that we need something like namespaces.

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

[nemo]

[-- Attachment #1: Type: text/plain, Size: 95 bytes --]

C

(or John Lions had to rewrite 6th in C before his notes;
which I think he didn't) ☺


[-- Attachment #2: Type: message/rfc822, Size: 1946 bytes --]

From: "Boyd Roberts" <boyd@planete.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] the declaration of main()
Date: Fri, 27 Apr 2001 01:50:48 +0200
Message-ID: <02a901c0ceab$b8286b40$e8b7c6d4@SOMA>

> C didn't really become widely used until after the 7th edition...

eh?  what was 6th ed written in?

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

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

>>Note that Forsyth's example is from 6th edition Unix, not 7th edition.
>>(The "s4/" in the source file name is a dead giveaway.)

i'm afraid not.

>>C didn't really become widely used until after the 7th edition, and
>>v7 C is really the ancestral root of most other implementations.  It is

the C compilers knew nothing of main, and if 7th edition really was the ancestral
root of most other implementations (which isn't so, because there were
some before 7th edition), they wouldn't have needed the invention
of EXIT_FAILURE and EXIT_SUCCESS.


[-- Attachment #2: Type: message/rfc822, Size: 2218 bytes --]

From: Mike Haertel <mike@ducky.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] the declaration of main()
Date: Thu, 26 Apr 2001 12:17:47 -0700 (PDT)
Message-ID: <200104261917.f3QJHlG03409@ducky.net>

Forsyth wrote:

>cpu% cat s4/crt0.s
>/ C runtime startoff

Note that Forsyth's example is from 6th edition Unix, not 7th edition.
(The "s4/" in the source file name is a dead giveaway.)

Here's the corresponding code fragment from 7th edition
/usr/src/libc/csu/crt0.s:

1:
	mov	r0,4(sp)
	mov	r0,_environ
	jsr	pc,_main
	cmp	(sp)+,(sp)+
	mov	r0,(sp)
	jsr	pc,*$_exit
	sys	exit

Here the int return value from main does indeed become the exit status.

C didn't really become widely used until after the 7th edition, and
v7 C is really the ancestral root of most other implementations.  It is
also the version of the language that most nearly coincided with the
publication of the 1st edition of "The C Programming Language".

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

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> the C compilers knew nothing of main, and if 7th edition really was the ancestral
> root of most other implementations (which isn't so, because there were
> some before 7th edition), they wouldn't have needed the invention
> of EXIT_FAILURE and EXIT_SUCCESS.

The C *implementations* certainly knew of main, as that is how
the user-provided program gets invoked by the C run-time
start-up module.  The ancestry has to do with the K&R book
and the influence of the UNIX interfaces upon implementors on
other platforms.  int main(argc,argv) might not be the best
interface for a specific platform, but it was (and is)
certainly standard for hosted environments (and some standalone
ones).  The int value returned by main (also passed to the
parent via exit) had certain conventional meanings on UNIX,
and as of 7th Edition it was standard for 0 to mean success
and various small positive numbers to indicate kinds of failure.
Platforms like VAX/VMS already had carefully designed process
status code schemes, for example on VMS a value of 1 actually
meant success.  Through long discussions (arguments) X3J11 was
able to engineer a solution that would work adequately on all
the existing platforms; we figured out a way for VMS to allow
0 to be returned and still indicate success, although they
would prefer a different code (that could be assigned to the
EXIT_SUCCESS macro).  Standardization is often like this; the
affected parties negotiate a mutually acceptable solution that
avoids invalidating (much of) their own customers' existing code.

As someone who has invested a lot of effort over decades to
this area, I find it frustrating when I encounter people who
don't realize that the C standard reflects a lot more than the
small amount of thought that they themselves have given the
matter.  There are good reasons behind the specifications,
and you make a heck of a lot less trouble for others if you
conform to the specifications insofar as possible.

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

[Boyd Roberts]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
>
> As someone who has invested a lot of effort over decades to
> this area, I find it frustrating when I encounter people who
> don't realize that the C standard reflects a lot more than the
> small amount of thought that they themselves have given the
> matter.

i got your point of view a long time ago [years].

i just don't agree, but i know what you're trying to achieve.

i don't agree because:

    general purpose solutions aren't

the ANSI C / small C argument has been done to death, so i
agree to disagree.  that's a taylor 'class 2 disaagreement'.

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

[Douglas A. Gwyn]

Boyd Roberts wrote:
> i don't agree because:
>     general purpose solutions aren't

Standards would be, except for bull-headedness on the part
of a small minority.  We even got the Gnu folks to appreciate
the value of providing standard conformance, while continuing
to innovate in other ways.

All that fighting a well-established standard does is to
isolate you from the rest of the world.  Do you really think
that there is no C code of value except for whatever has been
constructed specifically for Plan 9?

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

[William K. Josephson]

On Fri, Apr 27, 2001 at 04:22:31PM +0000, Douglas A. Gwyn wrote:
> Boyd Roberts wrote:
> > i don't agree because:
> >     general purpose solutions aren't
>
> Standards would be, except for bull-headedness on the part
> of a small minority.  We even got the Gnu folks to appreciate
> the value of providing standard conformance, while continuing
> to innovate in other ways.

I believe you mean "innovate".  ;-)

> All that fighting a well-established standard does is to
> isolate you from the rest of the world.  Do you really think
> that there is no C code of value except for whatever has been
> constructed specifically for Plan 9?

Of course not, but GNU, for instance, has very different objectives.
It is one thing to claim that there is valuable C source out there
other than what comes with Plan 9 and a very different thing to claim
that Plan 9 should support it.  In fact, in my experience, the Plan 9
source code is far *more* portable to other environments than most
Unix source is between Unix variants, for instance. I don't understand
your unwillingness to accept that Plan 9 as a research system need not
support legacy code beyond what the APE provides.  I am aware of at
least one other research system that did try to be standards compliant
and the result was that those working on the project spent far more
effort on engineering than research.  People can legitimately have
different priorities.

  -WJ

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

[Douglas A. Gwyn]

"William K. Josephson" wrote:
> ... I don't understand your unwillingness to accept that Plan 9
> as a research system need not support legacy code beyond what the
> APE provides.  I am aware of at least one other research system
> that did try to be standards compliant and the result was that
> those working on the project spent far more effort on engineering
> than research.  People can legitimately have different priorities.

Sure, I haven't been disputing that.  Actually Ken has already done
the "engineering" for the standard C language aspect and Howard has
already done the "engineering" for the standard C library aspect.
But apart from that, all I ask is that the researchers avoid
gratuitous incompatibility with the standard.  For example, using
the entry point name "mains" instead of "main" would not have
entailed any noticeable amount of extra work.  (Changing it now
would involve some work.  This is an example of the well-known fact
that fixing problems earlier in the development cycle is much less
expensive than fixing them later.)

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

[Boyd Roberts]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
>
> All that fighting a well-established standard does is to
> isolate you from the rest of the world.  Do you really think
> that there is no C code of value except for whatever has been
> constructed specifically for Plan 9?

obviously not.  so we're stuck on a 'class 1 disagreement'.
ie. you don't understand my position.

a bad standard is worse than no standard at all.

datakit was a 'standard':

    not known to work reliably at any speed, but the code is huge

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

[Greg Hudson]

(In the futile hope of bringing this thread to an earlier close:)

Douglas Gwyn wrote:
> All that fighting a well-established standard does is to isolate you
> from the rest of the world.  Do you really think that there is no C
> code of value except for whatever has been constructed specifically
> for Plan 9?

You're questioning the basic assumption of Plan 9, which is: let's try
to make an interesting and elegant system by abandoning the base of
existing Unix and ANSI C software and making all the design decisions
as if in a vacuum.  The system looks a little like Unix and the
language looks a lot like C only because there's some overlap between
the designers of Plan 9 and the designers of Unix and C.

Yeah, Plan 9 is unlikely to achieve a significant market position as a
result, but that's okay; it's a research project.  If you think people
shouldn't do this kind of research, fine, but you're not going to
convince them to stop by holding extended conversations on their
mailing list.  (Particularly not by sparring with the misguided fans
who really do think there isn't much C code of value apart from what
the Plan 9 group has written, or who think that the ANSI C committee
was populated largely by untrained monkeys.)

Yes, main() could have been renamed to strmain() or start() or
whatever.  It would have been less elegant (since main is, after all,
a good name) and ANSI C programs still wouldn't run normally because
the loader wouldn't know how to invoke main() (since the designers
don't want to pollute the system with backward compatibility
features).  Really, your issue is not with that particular decision
but with the basic design goals of the system, and those are unlikely
to change.

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

[Dan Cross]

In article <200104281554.LAA13061@egyptian-gods.MIT.EDU> you write:
>Yes, main() could have been renamed to strmain() or start() or
>whatever.  It would have been less elegant (since main is, after all,
>a good name) and ANSI C programs still wouldn't run normally because
>the loader wouldn't know how to invoke main() (since the designers
>don't want to pollute the system with backward compatibility
>features).  Really, your issue is not with that particular decision
>but with the basic design goals of the system, and those are unlikely
>to change.

I don't agree that this is what Doug is saying; I think he's just
saying that compatability could have been achieved in a more seamless
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!)

Also, you're off on the linker part; he gave an example of a library
function which would, ``do the right thing'' in that arena.  (The C
startup code would invoke mains(), taken out of a library, which, in
turn, would call main()).

On a personal note, I think that ``mains()'' is a cool name.

I don't think that anyone is saying that there's no useful software
written under Unix or in ISO C (note, for instance, that awk is brought
in under the APE).  The question is more, ``is the APE sufficient for
supportng that software?''  In most cases, I think so.  The other part
of the equation, and one which I think Doug is addressing is, ``is the
APE sufficient for writing software to port to other systems?''  Again,
I think so; though I've never tried.  True, one cannot easily mix and
match `native' Plan 9 and APE functions, but I think that might be a
good thing.

	- Dan C.

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

[Boyd Roberts]

could we please end this?

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

[Douglas A. Gwyn]

Dan Cross wrote:
> ...  The other part of the equation, and one which I think Doug is
> addressing is, ``is the APE sufficient for writing software to port
> to other systems?''

I agree with the rest of Dan's posting.  My concern is more for
bringing existing useful tools into Plan 9.  Often these have the
form of library functions that link with the Standard C library,
but one would want to use them in the native Plan 9 environment as
well as for APE applications.  Therefore, conflicts between these
environments cause very real problems in making effective use of
Plan 9 as a base for work on new things (i.e. research).

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

[forsyth]

>>Except for Plan 9's native (non-APE) and some standalone environments, main() *does*
>>in fact return an int, even if many programmers believed
>>otherwise.

oh well, i had good reason for my own belief:

cpu% cat s4/crt0.s
/ C runtime startoff

.globl	savr5

.globl	_main

start:
	setd
	mov	sp,r0
	mov	(r0),-(sp)
	tst	(r0)+
	mov	r0,2(sp)
	jsr	pc,_main
	cmp	(sp)+,(sp)+
	clr	r0
	sys	exit

.bss
savr5:	.=.+2

it doesn't look like main returns much to me.
given that the language hadn't even got void at that
point, how else was it to be declared but
	main(...)

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

[Mike Haertel]

Forsyth wrote:

>cpu% cat s4/crt0.s
>/ C runtime startoff

Note that Forsyth's example is from 6th edition Unix, not 7th edition.
(The "s4/" in the source file name is a dead giveaway.)

Here's the corresponding code fragment from 7th edition
/usr/src/libc/csu/crt0.s:

1:
	mov	r0,4(sp)
	mov	r0,_environ
	jsr	pc,_main
	cmp	(sp)+,(sp)+
	mov	r0,(sp)
	jsr	pc,*$_exit
	sys	exit

Here the int return value from main does indeed become the exit status.

C didn't really become widely used until after the 7th edition, and
v7 C is really the ancestral root of most other implementations.  It is
also the version of the language that most nearly coincided with the
publication of the 1st edition of "The C Programming Language".

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

[Boyd Roberts]

> C didn't really become widely used until after the 7th edition...

eh?  what was 6th ed written in?

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

[Douglas A. Gwyn]

Boyd Roberts wrote:
> > C didn't really become widely used until after the 7th edition...
> eh?  what was 6th ed written in?

I think the fellow's point was that it wasn't *widely* used,
meaning outside the Bell system.  Publication of K&R's book
was instrumental in gaining it a wider user base.

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

[Boyd Roberts]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
> I think the fellow's point was that it wasn't *widely* used,
> meaning outside the Bell system.  Publication of K&R's book
> was instrumental in gaining it a wider user base.

6th ed was in sydney in 1975.  the lions books anyone?

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

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> cpu% cat s4/crt0.s

Yeah, I did that too (actually I disassembled crt0.o since I
didn't have the V7 sources at hand), and was puzzled why it
didn't work the way I remembered.  But when linked with a
stdio-using test program the behavior was different.

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

[rog]

gwyn@arl.army.mil wrote:
> forsyth@vitanuova.com wrote:
> > it's unfortunately more error prone than void/exit.  for instance, it was
> > common to forget fflush() in the presence of setbuf/setvbuf in main for an auto buffer
> > and worse, that sometimes `worked' (until ported).
>
> I don't understand what you're talking about.

consider:

	#include <stdio.h>
	int main(void)
	{
		char buf[100];
		setvbuf(stdout, buf, _IOFBF, sizeof(buf));
		printf("hello, world\n");
		return 0;
	}

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

[Steve Kilbane]

> gwyn@arl.army.mil wrote:
> > forsyth@vitanuova.com wrote:
> > > it's unfortunately more error prone than void/exit.  for instance, it was
> > > common to forget fflush() in the presence of setbuf/setvbuf in main for an auto buffer
> > > and worse, that sometimes `worked' (until ported).
> >
> > I don't understand what you're talking about.
>
> consider:
>
> 	#include <stdio.h>
> 	int main(void)
> 	{
> 		char buf[100];
> 		setvbuf(stdout, buf, _IOFBF, sizeof(buf));
> 		printf("hello, world\n");
> 		return 0;
> 	}

Hold on. That's not a justification for the type of main().
It's Just Plain Bad. Saying that you wouldn't have a problem
if you were forced to exit() instead is a bogus argument, because
things would still go wrong if you forgot to call exit() (so you're
exchanging one programming error for another), or if you had the
buffer in a deeper scope, but called exit() as required.

steve

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

[forsyth]

i realised later that i hadn't pointed out that regardless whether
int main was a good choice for the C standard, it had further
disadvantages in plan 9.

plan 9 does not use an integer for exit status: it uses a string.
if it's considered desirable to return status from main, it would
need to be char*, which is still different from the C standard.
it could remain int if a return of zero mapped to "" and
non-zero mapped to "glenda", but exits(char*) would still
need to be called by main in general.  if that appears at the
end of main, compilers that detect flowing off the end of
a function-returning-value will either give a diagnostic
or need some hack (another pragma, great) to know about
exits.  all right, you could have some function to set a int->char*
map for the return value of main but things are
already getting out of hand.   void main was the better choice.

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

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> i realised later that i hadn't pointed out that regardless whether
> int main was a good choice for the C standard, it had further
> disadvantages in plan 9.

It needn't have.  Standard C of necessity provides a "lowest
common denominator" fit to existing target environments;
there are many systems (including Unix and VMS) that report
termination status as more than just success/failure, but
they do it in different ways.  Except for Plan 9's native
(non-APE) and some standalone environments, main() *does*
in fact return an int, even if many programmers believed
otherwise.  (On many platforms it is accidentally possible
to misdeclare main() and still get an executable that appears
to work.)  The C standard had to codify existing practice
(where there was already consensus), not try to change it.

> plan 9 does not use an integer for exit status: it uses a string.
> if it's considered desirable to return status from main, it would
> need to be char*, which is still different from the C standard.

No, there was an unhappy design decision.  Since there was
already a standard interface definition for the external
function name "main", Plan 9's startup entry point for user
code should have been given a different name, perhaps "start"
or "mains".  Then the Plan 9 library would provide a function:
	/* mains -- no need for APE since we conform to C99 */
	char *mains(int argc, char **argv) {
		exits(main(argc, argv) ? "FAILED" : "");
	}

> ...  void main was the better choice.

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.

As a general design principle, whenever you find that two
similar but different approaches have been created, there
has been a lack of vision.  We see this in the two kinds
of "character" support in Standard C, for another example.

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

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

>okamoto@granite.cias.osakafu-u.ac.jp wrote:
>> I wonder why C99 employed that int main(),
>
>Existing practice, tracable back to UNIX.

I should have asked why C99 employed _fixed_ definition as the main()'s
return value to INT only.  I don't understand it, if the answer is "practice".

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2119 bytes --]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] the declaration of main()
Date: Mon, 23 Apr 2001 08:44:09 GMT
Message-ID: <3AD61574.8E819DA9@arl.army.mil>

okamoto@granite.cias.osakafu-u.ac.jp wrote:
> I wonder why C99 employed that int main(),

Existing practice, tracable back to UNIX.

The previous response was incomplete; int-valued main
is apparently supported per the C standard if the pcc
(POSIX) compilation environment is used instead of the
native Plan 9 environment.

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

[Boyd Roberts]

From: <okamoto@granite.cias.osakafu-u.ac.jp>
>
> I should have asked why C99 employed _fixed_ definition as the main()'s
> return value to INT only.  I don't understand it, if the answer is "practice".

i do.  it was agreed on by a committee who wanted to live in the past.

doug will not agree with me, but i understand where he's coming from.

C is old.  it's time to move on.  been like that for a long time.

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

[dmr]

Forsyth said,

 > although it was possible to return a status from main by 6th edition
 > (in 5th edition returning from main did exit(0)), and only su included
 > return from main, arguably wrongly in 5th edition and definitely so in
 > 6th.  when i looked recently, i could find only two commands using it
 > in 7th edition (makekey and graph, both returning 0).

5th and 6th did behave as Charles says.  The real difference
between them and the 7th was that almost no use was
made of status returns, (either exit() or return value of main),
in the earlier ones.  Many things just flowed off
the end of main.  Between 6th and 7th, most things were
fixed, in part because Bourne installed a version of his
shell that announced every non-zero termination.
Also things like make arrived, and non-zero returns
began to be treated more often as errors.

	Dennis

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

[forsyth]

>>okamoto@granite.cias.osakafu-u.ac.jp wrote:
>>> I wonder why C99 employed that int main(),

>>Existing practice, tracable back to UNIX.

although it was possible to return a status from main by 6th edition
(in 5th edition returning from main did exit(0)), and only su included
return from main, arguably wrongly in 5th edition and definitely so in
6th.  when i looked recently, i could find only two commands using it
in 7th edition (makekey and graph, both returning 0).  the UNIX programming
paper encouraged the use of exit to ensure reliable exit status for a caller.

return from main seemed to me to be used mainly by the System III/V crowd,
rather later.

it's unfortunately more error prone than void/exit.  for instance, it was
common to forget fflush() in the presence of setbuf/setvbuf in main for an auto buffer
and worse, that sometimes `worked' (until ported).

i like the plan 9 conventions, myself.

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

[Boyd Roberts]

From: <forsyth@vitanuova.com>
>
> it's unfortunately more error prone than void/exit.  for instance, it was
> common to forget fflush() in the presence of setbuf/setvbuf in main for an
auto buffer
> and worse, that sometimes `worked' (until ported).
>
> i like the plan 9 conventions, myself.

yup

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

[Douglas A. Gwyn]

forsyth@vitanuova.com wrote:
> it's unfortunately more error prone than void/exit.  for instance, it was
> common to forget fflush() in the presence of setbuf/setvbuf in main for an auto buffer
> and worse, that sometimes `worked' (until ported).

I don't understand what you're talking about.  In 7th Edition
Unix, which is where exit status and stdio were first widely
used, return from main() (with or without a value) would
automatically invoke the exit() function, which in turn
invoked cleanup(), which if any stdio function was used
would link with the buffer-flushing version instead of the
no-op version.  Explicitly calling exit() would get the same
exit() function, the same cleanup() function, etc.

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

[Boyd Roberts]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
> I don't understand what you're talking about.  In 7th Edition
> Unix, which is where exit status and stdio were first widely
> used, return from main() (with or without a value) would
> automatically invoke the exit() function, which in turn
> invoked cleanup(), which if any stdio function was used
> would link with the buffer-flushing version instead of the
> no-op version.  Explicitly calling exit() would get the same
> exit() function, the same cleanup() function, etc.

yep, IIRC, sounds like the 7th ed /lib/crt0.s which eventually
called _exit() [the syscall].  exit() was a library function
which did the above and then called _exit().

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

[Douglas A. Gwyn]

Boyd Roberts wrote:
> yep, IIRC, sounds like the 7th ed /lib/crt0.s which eventually
> called _exit() [the syscall].  exit() was a library function
> which did the above and then called _exit().

I think there was a linker trick (similar to the floating-point
trick) to get the appropriate runtime startup behavior depending
on whether stdio functions had been invoked or not; at least,
when I tried the experiment on 7th Ed. UNIX at the time I
posted (to make sure I remembered correctly), the flushing
version of exit() got invoked from the startup function.

Note that in PDP-11 UNIX C, C externs have an underscore
prefixed to them at the linker level; so _exit in assembler
corresponds to exit() in C.  There is also _exit() in C, i.e.
__exit in assembler, which is the plain system call you
described, but from assembler one would not call that extern
function but would rather use a "sys" (TRAP) instruction
with the proper subcode to select the exit syscall.  There
were (optional) assembler macros for the syscall subcodes.

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

[Boyd Roberts]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
> Note that in PDP-11 UNIX C, C externs have an underscore
> prefixed to them at the linker level; so _exit in assembler
> corresponds to exit() in C.  There is also _exit() in C, i.e.
> __exit in assembler, which is the plain system call you
> described, but from assembler one would not call that extern
> function but would rather use a "sys" (TRAP) instruction
> with the proper subcode to select the exit syscall.  There
> were (optional) assembler macros for the syscall subcodes.

yep, that's right.  now i remember.  i think the _'s got as far
as 32V or TS1.2 or whatever it was called.  but that's going
back some 15+ years so i don't recall that well.  i'm pretty
sure that i saw it with adb with that system on our 11/780s.

the day USG killed adb i wanted to kill USG. system V -- what
a mess.

sdb?  what a joke.

crash?  what a joke.

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

[Boyd Roberts]

> I think there was a linker trick (similar to the floating-point
> trick) to get the appropriate runtime startup behavior depending
> on whether stdio functions had been invoked or not; at least,
> when I tried the experiment on 7th Ed.

yeah, that sounds familiar.

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

[Greg Hudson]

> I don't understand what you're talking about.  In 7th Edition Unix,
> which is where exit status and stdio were first widely used, return
> from main() (with or without a value) would automatically invoke the
> exit() function, which in turn invoked cleanup(), which if any stdio
> function was used would link with the buffer-flushing version
> instead of the no-op version.  Explicitly calling exit() would get
> the same exit() function, the same cleanup() function, etc.

rog was kind of terse, so:

If you return from main, the cleanup handler will be called, but all
of main's automatic variables (including the buffer you passed to
setvbuf()) are no longer valid.  If you explicitly call exit(), then
main()'s automatic variables are still valid.

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

[Douglas A. Gwyn]

Greg Hudson wrote:
> If you return from main, the cleanup handler will be called, but all
> of main's automatic variables (including the buffer you passed to
> setvbuf()) are no longer valid.  If you explicitly call exit(), then
> main()'s automatic variables are still valid.

Oh, okay.  One of a zillion potential pitfalls that a C
programmer needs to avoid.

Patient: Doctor, it hurts when I do *this*!
Doctor: So don't do *that*!

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

[okamoto]

nclude: /mail/fs/mbox/109/raw

I wonder why C99 employed that int main(), because I believe main()
makes a boundary between underlying OS and C language domain.
It means one should choose whichever s/he likes.  :-)

Kenji

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

[Douglas A. Gwyn]

okamoto@granite.cias.osakafu-u.ac.jp wrote:
> I wonder why C99 employed that int main(),

Existing practice, tracable back to UNIX.

The previous response was incomplete; int-valued main
is apparently supported per the C standard if the pcc
(POSIX) compilation environment is used instead of the
native Plan 9 environment.

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

[Boyd Roberts]

<okamoto@granite.cias.osakafu-u.ac.jp> a crit dans le message news:
20010412062827.2E4F919A17@mail.cse.psu.edu...
> I wonder why C99 employed that int main(), because I believe main()
> makes a boundary between underlying OS and C language domain.
> It means one should choose whichever s/he likes.  :-)


i'm sure doug can tell you.

IIRC plan 9 is written in 'ken C'.

--
Boyd Roberts        http://www.insultant.net        boyd@insultant.net

What do you know about surfing, Major?  You're from goddamn New Jersey.

    -- Lt. Colonel Kilgore

[9fans] the declaration of main()

[YAMANASHI Takeshi]

A number of Plan 9 commands declare their main() as
`void main(int argc, **argv)'.  How should I understand
this?

I believed that main() should be declared returning a int.
Please comfort me saying that this is pretty well with the
Plan 9 C compilers.

Thanks.
--
YAMANASHI Takeshi

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

[andrey mirtchovski]

http://plan9.bell-labs.com/sys/doc/comp.html

to quote (before someone else does it :) :

In Plan 9 main is not integer-valued; it should call exits, which takes
a string argument
(or null; here ANSI C promotes the 0 to a char*). All these functions
are, of course, documented in the Programmer's Manual.

andrey

YAMANASHI Takeshi wrote:

> A number of Plan 9 commands declare their main() as
> `void main(int argc, **argv)'.  How should I understand
> this?
>
> I believed that main() should be declared returning a int.
> Please comfort me saying that this is pretty well with the
> Plan 9 C compilers.
>