paone@topaz.rutgers.edu.UUCP (05/13/88)
I have been playing with my v1.1 of Megamax C and found what appears to be a bug in c lib. argc is being initialized to 1 instead of 0 so even when no arguments are passed, argc is 1. I went into the library and patched this up, but the argv also appears to be off. Is this the case, or is this supposed to be different from UNIX's method of handling them (Yes, I know argv[0] does not work)? Thanks, Phil Paone -- Phil Paone paone@topaz.rutgers.edu ihnp4!moss!oac!ppaone "Admiral...There be whales here"
jac423@leah.Albany.Edu (Julius A Cisek) (05/13/88)
In article <May.12.20.53.04.1988.25733@topaz.rutgers.edu>, paone@topaz.rutgers.edu (Phil Paone) writes: > I have been playing with my v1.1 of Megamax C and found what appears > to be a bug in c lib. argc is being initialized to 1 instead of 0 so > even when no arguments are passed, argc is 1. I went into the library > and patched this up, but the argv also appears to be off. Is this the > case, or is this supposed to be different from UNIX's method of > handling them (Yes, I know argv[0] does not work)? There is always at least 1 argument, the name of the program itself. It is the same way on the UNIX as on the ST as in any implementation of C. -- What about technology, computers, .------------------. J.A.Cisek nuclear fusion? I'm terrified of |Spectral Fantasies| jac423@leah.albany.edu radiation, I hate the television. `------------------' jac423@uacsc1.albany.edu
michel@megamax.UUCP (Michel Rynderman) (05/13/88)
argc was set to be 1 always because of compatibility with UNIX(TM). A lot
of programs count on the name of the program to be in argv[0]. The ST
does not pass the name of the program so argv[0] is set to a string with
nothing in it.("").
Hope this helps.
Michel@megamax
--
Anyone who would like a reply to their mail sent to me needs to give a
uucp path. The mailer on our system is weird. Either that or give me a
tel. number and I'll give you a call.
UUCP: pollux!megamax!michel PHONE: 214-987-4931csan@its63b.ed.ac.uk (A Ness) (05/16/88)
In article <May.12.20.53.04.1988.25733@topaz.rutgers.edu> paone@topaz.rutgers.edu (Phil Paone) writes: >> >I have been playing with my v1.1 of Megamax C and found what appears >to be a bug in c lib. argc is being initialized to 1 instead of 0 so >even when no arguments are passed, argc is 1. I went into the library >and patched this up, but the argv also appears to be off. Is this the >case, or is this supposed to be different from UNIX's method of >handling them (Yes, I know argv[0] does not work)? >-- Excuse me if I'm wrong - but isnt it true that you have used an argument - ie. the program name ? In fact I just tried it on two of our Un*x boxes and this is indeed the case - argc should be >=1 argv[0] should be the program name (I know it isnt on the ST),and argv[1]..argv[--argc] contains the arguments. Andie Ness . Department of Computer Science ,Edinburgh University. ARPA: csan%ed.itspna@nss.cs.ucl.ac.uk UUCP: ...!uunet!mcvax!ukc!itspna!csan an%ed.lfcs@nss.cs.ucl.ac.uk JANET: csan@uk.ac.ed.itspna an@uk.ac.ed.lfcs % These are my own views and any resemblance to any coherent reasoning is % probably a typo.
tainter@ihlpg.ATT.COM (Tainter) (05/17/88)
In article <May.12.20.53.04.1988.25733@topaz.rutgers.edu>, paone@topaz.rutgers.edu (Phil Paone) writes: > > I have been playing with my v1.1 of Megamax C and found what appears > to be a bug in c lib. argc is being initialized to 1 instead of 0 so > even when no arguments are passed, argc is 1. I went into the library > and patched this up, but the argv also appears to be off. Is this the > case, or is this supposed to be different from UNIX's method of > handling them (Yes, I know argv[0] does not work)? >-- Phil Paone Phil, you are confused. This is UNIX's method. Unix never gives you an argc < 1, since you always have the name of your program in argv[0]. On the ST they stick some fake name in argv[0]. (I patched mine so it always says "stupidity". Go back and unpatch your library! You know, I really hate the fact that argv[0] isn't initialized intelligently! If I get annoyed enough I'll come up with some not quite portable way of getting at the program name, and patch it into my prolog code. --j.a.tainter
rargyle@wsccs.UUCP (Bob Argyle) (05/21/88)
In article <May.12.20.53.04.1988.25733@topaz.rutgers.edu>, paone@topaz.rutgers.edu (Phil Paone) writes: > > I have been playing with my v1.1 of Megamax C and found what appears > to be a bug in c lib. argc is being initialized to 1 instead of 0 so > even when no arguments are passed, argc is 1. I went into the library > and patched this up, but the argv also appears to be off. ... > Phil Paone ... > "Admiral...There be whales here" There is apparently one unusable argument passed, the name of the program. argv[1] _always_ is the first argument after the program name. So argc = 2 so one can for (i=1;i<argc;i++) printf("%s\n",argv[i]); instead of kluging for (i=1;i<argc+1;i++)... to get the list. ^^ If it ain't broke ... when all else fails ... Bob @ wsccs
leo@philmds.UUCP (Leo de Wit) (06/13/88)
In article <46700006@hcx1> devon@hcx1.SSD.HARRIS.COM writes:
argc will always be at least 1. This is because the first parameter
passed (*argv[0]) will always be the name of the program. If an actual
parameter is passed from the shell argc will be 2 and the parameter will
be found in *argv[1]. A call with no parameters generates:
% ls
argc=1
*argv[0]="ls"
whereas a call with multiple parameters generates:
% ls file1 file2
argc=3
*argv[0]="ls"
*argv[1]="file1"
*argv[2]="file2"
It should be noted that this is not a bug in the libraries but conforms
exactly to the UNIX/C standards and is well documented in the K&R bible.
Everywhere you write '*argv' this should be: 'argv'. Note that argv is declared
char *argv[]; this means argv points to an array of pointers to char.
E.g. argv[1] is such a pointer, *argv[1] is the first character of the string
argv[1] points to. Note also that for the ST the name of the program is NOT
passed; this is because what the program really gets is an arguments line, that
it has to scan itself. The startup code that is linked with your modules should
take care of that; there is generally no way for it to determine the name it
was called with (some startup code make it a null pointer but I don't think
this is correct: in Un*x the first null pointer determines the end of the list)
. In Un*x the arguments and environment string arrays are already there when
the program starts.
Leo.