Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP Path: utzoo!linus!philabs!cmcl2!floyd!clyde!burl!ulysses!allegra!jpl From: jpl@allegra.UUCP (John P. Linderman) Newsgroups: net.unix-wizards Subject: Re: new topic...exorcising externs Message-ID: <2515@allegra.UUCP> Date: Fri, 8-Jun-84 09:30:26 EDT Article-I.D.: allegra.2515 Posted: Fri Jun 8 09:30:26 1984 Date-Received: Sat, 9-Jun-84 07:49:37 EDT References: <311@zeus.UUCP> Organization: AT&T Bell Laboratories, Murray Hill Lines: 24 There are a number of situations where externals are both cleaner and more convenient than parameter passing. One instance that comes to mind is "errno". I wouldn't hold it up as the paradigm of clean design, but it beats passing a pointer to an error value to every system call. Another favorite of mine is to declare an external char *Progname; and then do Progname = argv[0]; or Progname = p = argv[0]; while (*p) if (*p++ == '/') Progname = p; in the main routine to set Progname to the name (or basename) of the command as it was invoked. Being external, the name is available to diagnostic routines without having to be passed around. This eliminates the problems of building the command name into the command (suppose it gets linked or installed under a different name) and encouraging the use of the command name in all error diagnostics (don't you just love it when you run a pipeline of commands and one of them prints: malloc failed. and then dies without identifying itself? It would almost be better if it missed the check and dropped a core, so you could run a "strings" on the core and find out who it was.) John P. Linderman Department of External Affairs allegra!jpl