From owner-freebsd-audit Fri May 4 4:45:22 2001 Delivered-To: freebsd-audit@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D882E37B43C for ; Fri, 4 May 2001 04:45:17 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA04691; Fri, 4 May 2001 21:45:09 +1000 Date: Fri, 4 May 2001 21:42:37 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dima Dorfman Cc: audit@FreeBSD.ORG Subject: Re: {get,set}progname functions In-Reply-To: <20010502060949.23EFC3E28@bazooka.unixfreak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 1 May 2001, Dima Dorfman wrote: > Bruce Evans writes: > > I think setprogname() should not be a stub. setproctitle() can be > > used to change the process's name, so why should setprogname() be > > weaker? Perhaps setproctitle() should affect __progname (or at least > > the result returned by getprogname()), and setprogname() shouldn't > > exist. > > setproctitle() and setprogname() are supposed to change different > things. setproctitle() sets the name of the program as it should show > up in ps(1). Things like sendmail use it to show their status (e.g., > "sendmail: accepting connections"). Conversely, setprogname() sets > the program name as should be reported by err(3) and friends. I don't > think the authors of sendmail have output like > > sendmail: accepting connections: some random error > > in mind when they write > > warn("some random error"); OK. They are logically separate, so it is simpler for them to have no interactions. > That said, you're right that setprogname() shouldn't be a stub. In > the corrected path (below), it simply sets __progname. The fact that > the pointer passed to it is kept for the duration of the program's > life cycle is documented, so I think it's okay. OK. > > > +const char *getprogname __P((void)); > > I think this prototype should be formatted as: > > > > const char * > > getprogname __P((void)); > > > > like all the other prototypes for all the other functions whose return > > type (name) is longer than 7. > > All the rest of the prototypes aren't formatted quite like that. E.g.: > > unsigned short > *seed48 __P((unsigned short[3])); > > The placement of the '*' differs. Personally, I think the way you > suggest looks better, so that's the way I wrote it in the new patch. > But which one's right? The others also have a 9-char indent if they don't have a '*'. The '*' looks better when it's in the same column (before the function name) for all cases, although it logically doesn't really belong there. > As mentioned before, a corrected patch is attached. OK... > --- /dev/null Tue May 1 20:04:30 2001 > +++ lib/libc/gen/getprogname.c Tue May 1 22:58:10 2001 > @@ -0,0 +1,14 @@ > +#ifndef lint > +static const char rcsid[] = > + "$FreeBSD$"; > +#endif /* not lint */ Use LIBC_RCS as well as "lint" here (see libc/gen/err.c; other files mostly use LIBC_SCCS but I think we plan to change them, at least if the id is not an sccsid). > + > +extern const char * > + __progname; The line break for indenting the variable name is a bit much. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message