jimm@amiga.UUCP (Jim Mackraz) (02/09/89)
I need a new make.
Aztec make doesn't use Execute(), which is a problem for the WShell
environment (if you run patchdos, Execute will use NewShell, which is
faster, searches REXX:, and uses the WShell resident stuff).
LMK from lattice isn't sufficiently compatible with unix make (e.g., it
won't recompile a .c file after you edit it, which is kinda weird).
Anyone using a reliable, compatible make which uses Execute?
Thanks.
jimm
--
Jim Mackraz, I and I Computing "Like you said when we crawled down
{cbmvax,well,oliveb}!amiga!jimm from the trees: We're in transition."
- Gang of Four
Opinions are my own. Comments are not to be taken as Commodore official policy.dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (02/10/89)
:I need a new make. : :Aztec make doesn't use Execute(), which is a problem for the WShell :environment (if you run patchdos, Execute will use NewShell, which is :faster, searches REXX:, and uses the WShell resident stuff). : :LMK from lattice isn't sufficiently compatible with unix make (e.g., it :won't recompile a .c file after you edit it, which is kinda weird). : :Anyone using a reliable, compatible make which uses Execute? : :Thanks. : jimm Gee Jim, I don't know of any Make's that *can* use Execute(), god knows I've tried. The problem, of course, is that one needs to retrieve the exit code ... I would gladly use Execute() if I could retrieve the exit code. That is, assuming the compiler makers fix their exit() code properly. I don't know about Lattice, but Aztec does NOT set the DOS exit code fields (so, for example, even if I did use Execute() and it did return the exit code, it would still not work with Aztec's cc & other utilities, or any programs I write). -Matt
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (02/11/89)
In article <8902100715.AA16566@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > Gee Jim, I don't know of any Make's that *can* use Execute(), god >knows I've tried. The problem, of course, is that one needs to retrieve the >exit code ... > > I would gladly use Execute() if I could retrieve the exit code. After calling Execute(), IoErr() returns the DOS exit code. If I remember correctly, this was added in 1.2, and Andy Finkel discussed it some on BIX. I don't remember seeing it documented anywhere else. > That is, assuming the compiler makers fix their exit() code properly. >I don't know about Lattice, but Aztec does NOT set the DOS exit code fields >(so, for example, even if I did use Execute() and it did return the exit code, >it would still not work with Aztec's cc & other utilities, or any programs >I write). > > -Matt Lattice 5.0 sets the exit code properly. This seems to have been added when they added all the support for standard 1.3 resident programs--when compatibility with the standards started becoming more important, as Jimm pointed out. I have a version of the make on Fish disk 69 which I modified (trivially) to use Execute() instead of the Manx fexec(). It retrieves the exit code using IoErr(). To test it, I just wrote a test program (test.c) which does nothing but exit(20), and a makefile which invokes test. Typing 'make' returns a very gratifying "test failed (returncode 20)". All the parts of Lattice's compiler work just as nicely, and most can be made resident in the standard way. So, Jimm is asking for something completely reasonable. It works with Lattice 5.0. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (02/11/89)
In article <7381@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: <After calling Execute(), IoErr() returns the DOS exit code. If I remember <correctly, this was added in 1.2, and Andy Finkel discussed it some on BIX. <I don't remember seeing it documented anywhere else. It must have been documented somewhere else, because I knew about it, and don't ever read BIX. I can't remember where, though. <Lattice 5.0 sets the exit code properly. This seems to have been added <when they added all the support for standard 1.3 resident programs--when <compatibility with the standards started becoming more important, as <Jimm pointed out. The compiler may, but lc/lc1/lc2 don't. They always return 0 for IoError. Makes using execute in Make or (a cc command) pretty pointless - which is why I don't. <I have a version of the make on Fish disk 69 which I modified (trivially) <to use Execute() instead of the Manx fexec(). It retrieves the exit code <using IoErr(). To test it, I just wrote a test program (test.c) which <does nothing but exit(20), and a makefile which invokes test. Typing <'make' returns a very gratifying "test failed (returncode 20)". That message _isn't_ from Make; it's from Execute(). For a make, I don't want to see that message. Worse yet, you can't get the dos error code from IoErr for lc (though real dos commands give it to you), and Execute always hands back a -1 - no matter how well the command works. Finally, Lattice has the obnoxious habit of throwing away the value returned from main. <So, Jimm is asking for something completely reasonable. It works with <Lattice 5.0. I'd like to see a version of system that actually worked - with _any_ compiler. Can you provide that code for Lattice 5.0. <mike P.S - here's the code I used to test Execute and IoErr. I'd like a to use Execute for the same reasons that JimM would. Any help making it work would be appreciated. #include <stdio.h> main() { int status ; char buffer[1000] ; putchar('>') ; while (gets(buffer)) { status = Execute(buffer, (char *) 0, (char *) 0) ; printf("%d:%d>", IoErr(), status) ; } } -- He was your reason for living Mike Meyer So you once said mwm@berkeley.edu Now your reason for living ucbvax!mwm Has left you half dead mwm@ucbjade.BITNET
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (02/11/89)
[edited for television] In article <20212@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >In article <7381@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: ><I have a version of the make on Fish disk 69 which I modified (trivially) ><to use Execute() instead of the Manx fexec(). It retrieves the exit code ><using IoErr(). To test it, I just wrote a test program (test.c) which ><does nothing but exit(20), and a makefile which invokes test. Typing ><'make' returns a very gratifying "test failed (returncode 20)". >That message _isn't_ from Make; it's from Execute(). For a make, I >don't want to see that message. Worse yet, you can't get the dos error >code from IoErr for lc (though real dos commands give it to you), >and Execute always hands back a -1 - no matter how well the command >works. Oops. You're right. What I should have quoted is the line after "test failed", which read "make: Error code 20" (not the most helpful error message, but it did work). As for lc, when it fails, IoErr() returns a 1 on my system. I just tested that too. One big caveat which I should have remembered earlier: I am running Bill Hawes' WShell with his patch to Execute() which uses WShell. I don't know what all Bill does to Execute(), so I don't know if this works the same for a vanilla system. I just read through the Lattice startup code and couldn't find anywhere where the DOS return code is set--so I begin to suspect that this may be Bill's doing. Unfortunately, I'd have to reboot to find out. >I'd like to see a version of system that actually worked - with _any_ >compiler. Can you provide that code for Lattice 5.0. I used the arp SyncRun for a while--but then I had to deal with at least two incompatible resident lists, and it didn't work with BCPL commands. So I went back to Execute() when I started making the compiler passes resident. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (02/12/89)
:That message _isn't_ from Make; it's from Execute(). For a make, I
:don't want to see that message. Worse yet, you can't get the dos error
:code from IoErr for lc (though real dos commands give it to you),
:and Execute always hands back a -1 - no matter how well the command
:works.
:
:Finally, Lattice has the obnoxious habit of throwing away the value
:returned from main.
So, it seems that neither Aztec or Lattice set the DOS return code,
though they do return it in D0 (ignored by a CLI/Execute).
As for throwing away main's return value , this is what is supposed
to happen. That is, so the following:
main()
{
}
NO return at all (i.e. garbage in D0) is equivalent to returning 0.
If you want to return an exit code, you need to use exit(n). Unless you
*were* using exit(), in which case the first comment applies.
>I'd like to see a version of system that actually worked - with _any_
>compiler. Can you provide that code for Lattice 5.0.
Amen to that.
-Mattjesup@cbmvax.UUCP (Randell Jesup) (02/14/89)
In article <20212@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: ><Lattice 5.0 sets the exit code properly. This seems to have been added ><when they added all the support for standard 1.3 resident programs--when ><compatibility with the standards started becoming more important, as ><Jimm pointed out. > >The compiler may, but lc/lc1/lc2 don't. They always return 0 for >IoError. Makes using execute in Make or (a cc command) pretty >pointless - which is why I don't. Huh? lc/lc1/lc2 don't have to set IoErr(). They just have to return a non-0 return code. There was one beta 5.0 that never returned error codes, you wouldn't be using it, would you? ><I have a version of the make on Fish disk 69 which I modified (trivially) ><to use Execute() instead of the Manx fexec(). It retrieves the exit code ><using IoErr(). To test it, I just wrote a test program (test.c) which ><does nothing but exit(20), and a makefile which invokes test. Typing ><'make' returns a very gratifying "test failed (returncode 20)". > >That message _isn't_ from Make; it's from Execute(). For a make, I >don't want to see that message. Worse yet, you can't get the dos error >code from IoErr for lc (though real dos commands give it to you), >and Execute always hands back a -1 - no matter how well the command >works. Execute() never prints such a message. Execute returns DOS_TRUE if the command was executed (== -1), or 0 if it couldn't execute it (usually because it couldn't load it). LC has NO requirement to set IoErr to the value of an error IT got while doing an operation, all it has to do is return a non-0 return code. >Finally, Lattice has the obnoxious habit of throwing away the value >returned from main. That habit is the ANSI standard. main() is void. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (02/14/89)
In article <5963@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: <In article <20212@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: <><Lattice 5.0 sets the exit code properly. This seems to have been added <><when they added all the support for standard 1.3 resident programs--when <><compatibility with the standards started becoming more important, as <><Jimm pointed out. <> <>The compiler may, but lc/lc1/lc2 don't. They always return 0 for <>IoError. Makes using execute in Make or (a cc command) pretty <>pointless - which is why I don't. < < Huh? lc/lc1/lc2 don't have to set IoErr(). They just have to <return a non-0 return code. There was one beta 5.0 that never returned error <codes, you wouldn't be using it, would you? I never had the beta Lattice Compiler. IoErr() is supposed to give you the DOS return code from the command Execute ran ("further information"). I wasn't getting those from IoErr() until after I ran Bill Hawes PatchDOS program, which plugs in his version of Execute. Could it be that Execute is throwing away that information? <>That message _isn't_ from Make; it's from Execute(). For a make, I <>don't want to see that message. Worse yet, you can't get the dos error <>code from IoErr for lc (though real dos commands give it to you), <>and Execute always hands back a -1 - no matter how well the command <>works. < < Execute() never prints such a message. Ok, when _my_ code isn't printing that message, then who is? It could be the Lattice Execute() stub. Given the context of the comment (discussing using Execute() in Lattice C), this means Execute() said it. <Execute returns DOS_TRUE if <the command was executed (== -1), or 0 if it couldn't execute it (usually <because it couldn't load it). LC has NO requirement to set IoErr to the <value of an error IT got while doing an operation, all it has to do is return <a non-0 return code. Quite correct. But what becomes of the value returned by LC (or ehatever?). My understanding was that it became available via IoErr(). This may be an extension Bill Hawes put into his code. In which case, stock Execute is worthless for things like make (the original question was "is there a make that uses Execute()?"). And of course LC doesn't have to set IoErr - I didn't say it did. I said it "returned 0 for IoErr." I left of the ()'s, but that was in reply to a comment that there return value could be gotten via IoErr(). So either 1) they always return 0, or 2) that value is thrown away. I (naively, apparently) assumed that Lattice was more likely to be at fault than CBM. <>Finally, Lattice has the obnoxious habit of throwing away the value <>returned from main. < < That habit is the ANSI standard. main() is void. Section 2.1.2.2: int main(void) { /*...*/ } int main(int argc, char *argv[]) { /*...*/ } and A return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function, ... <mike -- I know the world is flat. Mike Meyer Don't try tell me that it's round. mwm@berkeley.edu I know the world stands still. ucbvax!mwm Don't try to make it turn around. mwm@ucbjade.BITNET
jac@ssibbs.UUCP (James Crotinger) (02/15/89)
In article <8902120648.AA14117@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > > NO return at all (i.e. garbage in D0) is equivalent to returning 0. > If you want to return an exit code, you need to use exit(n). Unless you > *were* using exit(), in which case the first comment applies. > A couple of the books I have, one on ANSI C, state that returning a value from main should be identical to calling exit(). In fact, they say it is perfectly allowable for the startup code to execute main() with the following call: exit(main(argc,argv)); In this respect, Lattice is in error since it prototypes main as being type void, where all the books I've seen (ANSI books) say main should have type int. > -Matt Jim -- Jim Crotinger crotinger%mit.mfenet@nmfecc.arpa
paolucci@snll-arpagw.UUCP (Sam Paolucci) (02/24/89)
In article <97@ssibbs.UUCP> jac@ssibbs.UUCP (James Crotinger) writes:
-> A couple of the books I have, one on ANSI C, state that returning a value
->from main should be identical to calling exit(). In fact, they say it is
->perfectly allowable for the startup code to execute main() with the following
->call:
->
-> exit(main(argc,argv));
->
-> In this respect, Lattice is in error since it prototypes main as being
->type void, where all the books I've seen (ANSI books) say main should have
->type int.
I called Lattice about 3 days ago about a bunch of non ANSI stuff in their
"ANSI" compiler, and I forgot to mention them exactly the above. You are
correct and Lattice is wrong on this point. I suggest you discuss this
with their tech support (or I will).
-> Jim Crotinger
-> crotinger%mit.mfenet@nmfecc.arpa
--
-+= SAM =+-
"the best things in life are free"
ARPA: paolucci@snll-arpagw.llnl.govjac@ssibbs.UUCP (James Crotinger) (02/26/89)
In article <5963@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > > That habit is the ANSI standard. main() is void. > I've seen three books which clearly state that main() returns type int. K&R v2.0 has numerous examples which "return" from main, and state on p. 26 that "Since main is a function like any other, it may return a value to its caller, which is in effect the environment in which the program was executed. Typically, a return value of zero implies normal termination; non-zero values signal unusual or erroneous termination conditions." Jaeschke, in "Portability and the C Language" states that "The method used to invoke main during program startup can vary. ANSI C requires that it be done as if the following code were used: exit(main(argc,argv)) ; in which case, any value returned explicitly or implicitly from main will be passed on as the program's exit code." (p. 25) Similarly, Harbison & Steel, 2nd Ed. state that main() should return type int. It seems to me that Lattice is in error on this point. > -- > Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup Jim -- Jim Crotinger crotinger%mit.mfenet@nmfecc.arpa