Re: Library __progname cleanups - commit candidate

Bruce Evans <[email protected]>
Newsgroups gmane.os.freebsd.devel.audit
Message-ID <[email protected]>
On Tue, 26 Mar 2002 [email protected] wrote:

> Index: csu/alpha/crt1.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/csu/alpha/crt1.c,v
> retrieving revision 1.10
> diff -u -d -r1.10 crt1.c
> --- csu/alpha/crt1.c	26 Oct 2001 06:45:10 -0000	1.10
> +++ csu/alpha/crt1.c	26 Mar 2002 12:11:31 -0000
> @@ -40,6 +40,7 @@
>  #endif
>
>  #include <stdlib.h>
> +#include <libc_private.h>

Angle-bracket includes are bogus for nonstandard includes.  They are
correctly not used in most places in old code.  Also, <libc_private.h>
would be unsorted if it belonged with the standard headers.  Similarly
elsewhere in these patches.

> Index: csu/i386/crt0.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/csu/i386/crt0.c,v
> retrieving revision 1.36
> diff -u -d -r1.36 crt0.c
> --- csu/i386/crt0.c	27 Aug 1999 23:57:55 -0000	1.36
> +++ csu/i386/crt0.c	26 Mar 2002 12:05:26 -0000
> @@ -37,10 +37,13 @@
>  #ifdef DYNAMIC
>  #include <sys/types.h>
>  #include <sys/syscall.h>
> -#include <a.out.h>
> -#include <string.h>
>  #include <sys/mman.h>

<sys/mman.h> is still unsorted.

> +
> +#include <a.out.h>
>  #include <link.h>
> +#include <string.h>
> +
> +#include "../../libc/include/libc_private.h"

Another bogus path.  You just added a -I to the Makefile so that the full
path is not needed here.

> Index: libc/gen/getprogname.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/libc/gen/getprogname.c,v
> retrieving revision 1.3
> diff -u -d -r1.3 getprogname.c
> --- libc/gen/getprogname.c	1 Feb 2002 00:57:29 -0000	1.3
> +++ libc/gen/getprogname.c	26 Mar 2002 08:33:48 -0000
> @@ -3,10 +3,12 @@
>
>  #include <stdlib.h>

This is missing includes of "namespace.h" and "un-namespace.h", except
you do things in a nonstandard way.  Similarly elsewhere.  Not so
similarly in err.c above (I limited the scopy of the namespace includes
too carefully there, so they don't already cover <stdlib.h>).

>
> -extern const char *__progname;
> +#include <libc_private.h>

As usual.

> +
> +__weak_reference(_getprogname, getprogname);
>
>  const char *
> -getprogname(void)
> +_getprogname(void)

OK.  This part of namespace hiding is easy.

> Index: libc/gen/setproctitle.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/libc/gen/setproctitle.c,v
> retrieving revision 1.15
> diff -u -d -r1.15 setproctitle.c
> --- libc/gen/setproctitle.c	1 Feb 2002 00:57:29 -0000	1.15
> +++ libc/gen/setproctitle.c	25 Mar 2002 21:20:39 -0000
> ...
> @@ -83,7 +84,7 @@
>  			len = 0;
>  		} else {
>  			/* print program name heading for grep */
> -			(void) snprintf(buf, sizeof(buf), "%s: ", __progname);
> +			(void)snprintf(buf, sizeof(buf), "%s: ", _getprogname());

Line too long.

> Index: libc/gmon/gmon.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/libc/gmon/gmon.c,v
> retrieving revision 1.13
> diff -u -d -r1.13 gmon.c
> --- libc/gmon/gmon.c	15 Feb 2002 02:37:08 -0000	1.13
> +++ libc/gmon/gmon.c	25 Mar 2002 21:22:48 -0000
> @@ -46,20 +46,21 @@
>  #include "namespace.h"
>  #include <err.h>
>  #include "un-namespace.h"

My bad.  This inner pair of namespace includes probably breaks the outer
pair.  The outer pair should already cover <stdlib.h>.

> Index: libc/include/libc_private.h
> ===================================================================
> RCS file: /home/ncvs/src/lib/libc/include/libc_private.h,v
> retrieving revision 1.4
> diff -u -d -r1.4 libc_private.h
> --- libc/include/libc_private.h	24 Jan 2001 13:00:08 -0000	1.4
> +++ libc/include/libc_private.h	25 Mar 2002 21:19:31 -0000
> @@ -63,4 +63,16 @@
>  #define	FLOCKFILE(fp)		if (__isthreaded) _FLOCKFILE(fp)
>  #define	FUNLOCKFILE(fp)		if (__isthreaded) _funlockfile(fp)
>
> +/*
> + * This is a pointer in the C run-time startup code. It is used
> + * by getprogname() and setprogname().
> + */
> +extern const char *__progname;
> +
> +/*
> + * Declare an internal version of getprogname() to allow for
> + * the programmer declaring her own.
> + */
> +const char *_getprogname(void);
> +

Why not use the standard namespace mechanism?  It just happens that
this header provides a convenient place to put prototype for the
implementatation name so that a less hackish mechanism can be used,
but this is surprising.

> Index: libc_r/uthread/uthread_spinlock.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_spinlock.c,v
> retrieving revision 1.9
> diff -u -d -r1.9 uthread_spinlock.c
> --- libc_r/uthread/uthread_spinlock.c	24 Jan 2001 13:03:36 -0000	1.9
> +++ libc_r/uthread/uthread_spinlock.c	25 Mar 2002 19:52:44 -0000
> ...
> -			snprintf(str, sizeof(str), "%s - Warning: Thread %p attempted to lock %p from %s (%d) was left locked from %s (%d)\n", __progname, curthread, lck, fname, lineno, lck->fname, lck->lineno);
> +			snprintf(str, sizeof(str), "%s - Warning: Thread %p attempted to lock %p from %s (%d) was left locked from %s (%d)\n", _getprogname(), curthread, lck, fname, lineno, lck->fname, lck->lineno);

Disgustingly long line longer than before.

> Index: libfetch/http.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/libfetch/http.c,v
> retrieving revision 1.51
> diff -u -d -r1.51 http.c
> --- libfetch/http.c	5 Feb 2002 22:13:51 -0000	1.51
> +++ libfetch/http.c	25 Mar 2002 19:53:14 -0000
> ...
> @@ -840,7 +838,7 @@
>  		if ((p = getenv("HTTP_USER_AGENT")) != NULL && *p != '\0')
>  			_http_cmd(fd, "User-Agent: %s", p);
>  		else
> -			_http_cmd(fd, "User-Agent: %s " _LIBFETCH_VER, __progname);
> +			_http_cmd(fd, "User-Agent: %s " _LIBFETCH_VER, _getprogname());

Long line longer than before.  Similarly elsewhere.

Bruce


To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-audit" in the body of the message
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.