Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!vsi1!wyse!mips!rogerk From: rogerk@mips.COM (Roger B.A. Klorese) Newsgroups: comp.unix.wizards Subject: Re: scrogged argc, argv (was: system 5 vrs. bsd4.3 question) Message-ID: <26935@abbott.mips.COM> Date: 6 Sep 89 01:54:57 GMT References: <28398@beta.lanl.gov> <10940@smoke.BRL.MIL> Reply-To: rogerk@mips.COM (Roger B.A. Klorese) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 49 In article <10940@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <28398@beta.lanl.gov> dxk@beta.lanl.gov (David M Koon) writes: >-#include >-#include >-#include >-#include "cffs.h" >-main(argc,argv) >-int argc; >-char *argv[]; >-{ >-.... >-However, on the SGI machine argc is undefined and argv seems to contain >-the environmental variables. Does anyone have any ideas as to what is >-causing this and how I can fix it? > >The last time someone asked this, it turned out that the preceding >header ("cffs.h" in this case) contained an error that affected the >apparent return type associated with main(). Fix "cffs.h". More specifically: if "cffs.h" ends with a struct declaration of the form struct foo { .... } rather than the proper struct foo { ... }; (note the semicolon) ...you get hit by the fact that the compiler then classes the return of main() as a struct foo, rather than as an int. The MIPS C compiler shifts the argument list over by one to accomodate the return value of a struct-valued function. This is cool, unless the function is declared as "struct foo" and called (by the startup code) as "int", in which case argv will be where you think argc ought to be, and envp will be where you think argv should be. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I want to live where it's always Saturday." -- Guadalcanal Diary