chris@mimsy.UUCP (Chris Torek) (05/31/89)
In some article whose referent is gone because Root Boy gets this stuff via a mailing list rather than netnews, I wrote: >>Programs that produce output should produce the output to stdout. In article <19756@adm.BRL.MIL> rbj@dsys.icst.nbs.gov (Root Boy Jim) writes: >I agree completely, Chris. Now get cracking on `cc', so that >`cc prog.c' writes to stdout instead of `a.out' :-) As you can see by the `:-)' sign, Jimmy C. is kidding. But there is much truth in this. The C compiler should write to stdout, unless there is some overriding reason that it cannot---and in fact, the compiler proper (/lib/ccom on many Unixes, or /lib/c0 and /lib/c1 on some others) *does* write to stdout. So does the C preprocessor (often /lib/cpp), and the peephole optimiser (/lib/c2). The assembler does not, but that is because its `output' is not something ordinary programs can deal with---and this excuse is quite weak---or because it wants to seek on the output file. (`ld' does a bit of seeking; but I am not at all sure about the many different assemblers out there.) At any rate, `cc' is clearly wrong to write to `a.out'. A much better approach would be for it to default to `cc prog.c' producing `prog' (or even `prog.out' or the like). It is probably too late to change it now, but that does not make it any less wrong. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/31/89)
In article <17796@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >As you can see by the `:-)' sign, Jimmy C. is kidding. But there is >much truth in this. The C compiler should write to stdout, unless >there is some overriding reason that it cannot... I can think of a moderately overriding reason that it should not. Generalizing: Programs should write to stdout when their output would make sense on a computer terminal, or when their output is likely to be redirected elsewhere and used properly. Programs that seek are an exception. Unfortunately, cc's output will put most terminals in a funny state, and cc is often invoked interactively. But "cc -o -" should write to stdout. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi Career change search is on -- ask me for my resume
evan@plx.UUCP (Evan Bigall) (06/01/89)
>In article <19756@adm.BRL.MIL> rbj@dsys.icst.nbs.gov (Root Boy Jim) writes: >>I agree completely, Chris. Now get cracking on `cc', so that >>`cc prog.c' writes to stdout instead of `a.out' :-) > >As you can see by the `:-)' sign, Jimmy C. is kidding. But there is >much truth in this. The C compiler should write to stdout, unless >there is some overriding reason that it cannot--- And to complete the circle, I would kill for a C compiler that would read from standard input so I could do: lex -t -n input.l | sed -f fixlex.sed | m4 -s debug.m4 - | cc -c - In this particular case, it would not even damage the error reporting abilities of the compiler because the -s flag to m4 enables line sync output. Of course -c would need to take an argument to say where to put the .o (or apply a suitable convention), and there might be troubles if the compiler seek's through the input. But, it would be so nice to avoid those temporary files. As a side note, what do people name .c files intended for m4 pre-processing? -- Evan Bigall, Plexus Computers, San Jose, CA (408)943-2283 ...!sun!plx!evan "I barely have the authority to speak for myself, certainly not anybody else"
chris@mimsy.UUCP (Chris Torek) (06/02/89)
In article <1954@plx.UUCP> evan@plx.UUCP (Evan Bigall) writes: >And to complete the circle, I would kill for a C compiler that would read >from standard input so I could do: > > lex -t -n input.l | sed -f fixlex.sed | m4 -s debug.m4 - | cc -c - On a 4BSD system, you could lex -t -n input.l | sed -f fixlex.sed | m4 -s debug.m4 | /lib/cpp | /lib/ccom | /lib/c2 | as -o input.o (remove /lib/c2 to avoid the equivalent of cc -O). Suns demand that the assembler input come from a file, unfortunately. Other machines may not even have a way to run the compiler guts directly. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jeff@quark.WV.TEK.COM (Jeff Beadles) (06/02/89)
In article <1954@plx.UUCP> evan@plx.UUCP (Evan Bigall) writes: > lex -t -n input.l | sed -f fixlex.sed | m4 -s debug.m4 - | cc -c - > >Of course -c would need to take an argument to say where to put the .o >(or apply a suitable convention) Gee, would that be a.o (a.out, a.o? :-) :-) -Jeff -- Jeff Beadles Utek Sustaining Engineering, Tektronix Inc. jeff@quark.WV.TEK.COM
roy@phri.UUCP (Roy Smith) (06/02/89)
In article <1954@plx.UUCP> evan@plx.UUCP (Evan Bigall) writes: > And to complete the circle, I would kill for a C compiler that would read > from standard input so I could do: I remember somebody (Henry Maslin?) used to link /dev/tty.c to /dev/tty so he could do "% cc /dev/tty.c" and type in a c program on the keyboard. Yowza! If you had /dev/stdin, you could easily play the same trick, linking /dev/stdin.c to /dev/stdin. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
cowan@marob.masa.com (John Cowan) (06/03/89)
In article <1954@plx.UUCP> evan@plx.UUCP (Evan Bigall) writes: >As a side note, what do people name .c files intended for m4 pre-processing? I call 'em "foo.c4". This extends nicely, to m4-requiring assembly source ("foo.s4"), makefiles ("foo.make4"), etc. etc. -- John Cowan <cowan@marob.masa.com> or <cowan@magpie.masa.com> UUCP mailers: ...!uunet!hombre!{marob,magpie}!cowan Fidonet (last resort): 1:107/711 Aiya elenion ancalima!
allbery@ncoast.ORG (Brandon S. Allbery) (06/04/89)
As quoted from <17796@mimsy.UUCP> by chris@mimsy.UUCP (Chris Torek): +--------------- | In some article whose referent is gone because Root Boy gets this stuff | via a mailing list rather than netnews, I wrote: | >>Programs that produce output should produce the output to stdout. | | In article <19756@adm.BRL.MIL> rbj@dsys.icst.nbs.gov (Root Boy Jim) writes: | >I agree completely, Chris. Now get cracking on `cc', so that | >`cc prog.c' writes to stdout instead of `a.out' :-) | | As you can see by the `:-)' sign, Jimmy C. is kidding. But there is | much truth in this. The C compiler should write to stdout, unless | there is some overriding reason that it cannot---and in fact, the +--------------- Just to be obnoxiously pedantic [ ;-) ]: "cc" doesn't write to a.out; "ld" does. This doesn't mean that "cc" and "ld" aren't atrociously implemented, however. The problem with "cc" is that it's a (supposedly) "smart" wrapper for the compiler, assembler, and linker; it knows about filename extensions so it can decide whether to pass something to /lib/ccom, as, or ld (and under System III and -- I hear -- SunOS4.0, it complains if it doesn't recognize the extension of a file). Yucch. If I want that, I'll use "make", where I can define the program to use as I see fit. I'd prefer that "cc" build the pipeline to cpp, ccom, and c2/optim/copt/ whatever-it's-called-on-system-xyzzy, then write the resulting assembly code to stdout; then the casual user can pipe that to "as", or let the Makefile deal with it (that being what "make" is for). "ld" is more similar to an archive maintenance utility than to a filter, but it could still do its seeking in a temporary file and write the resulting binary to stdout... and for a trivial (one object module, no libraries other than -lc) binary it could easily be modified to be used as "cc < foo.c | as | ld > foo". (If you want to use libraries, change that to "... | ld - -lbar > foo".) (For that matter, "ld" (and "cc") probably shouldn't have a shorthand notation for libraries. How about "LDPATH=/lib:/usr/lib:... export LDPATH"?) This is not only conceptually simpler and cleaner, but it exploits multiple processors without hackery. However, in the rush to get fancy "intuitive" user interfaces, little things like that don't get much shrift.... ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
allbery@ncoast.ORG (Brandon S. Allbery) (06/04/89)
As quoted from <7509@bsu-cs.bsu.edu> by dhesi@bsu-cs.bsu.edu (Rahul Dhesi): +--------------- | In article <17796@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: | >As you can see by the `:-)' sign, Jimmy C. is kidding. But there is | >much truth in this. The C compiler should write to stdout, unless | >there is some overriding reason that it cannot... | | I can think of a moderately overriding reason that it should not. | Generalizing: | | Programs should write to stdout when their output would make sense | on a computer terminal, or when their output is likely to be | redirected elsewhere and used properly. Programs that seek are an | exception. | | Unfortunately, cc's output will put most terminals in a funny state, | and cc is often invoked interactively. +--------------- By that argument, "cat /bin/sh > /dev/tty" should refuse to work because it's writing a binary file to the terminal. Foo. "...likely to be redirected elsewhere": if cc had been written correctly, people using it would know that it outputs a binary file and would therefore be "likely to be redirected elsewhere." (Actually, if "cc" had been written correctly, it would output assembly language, which is ASCII, so the point is moot.) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
allbery@ncoast.ORG (Brandon S. Allbery) (06/04/89)
As quoted from <13692@ncoast.ORG> by allbery@ncoast.ORG (Brandon S. Allbery): +--------------- | I'd prefer that "cc" build the pipeline to cpp, ccom, and c2/optim/copt/ | whatever-it's-called-on-system-xyzzy, then write the resulting assembly code +--------------- Come to think of it, the user can perfectly well pipe the output of cc to optim his/her/itself, as desired. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser