From owner-cvs-all@FreeBSD.ORG Sun Jul 27 13:58:20 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19EDA37B401; Sun, 27 Jul 2003 13:58:20 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2012743FB1; Sun, 27 Jul 2003 13:58:18 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.12.8/8.12.8) with ESMTP id h6RKwFV3031216; Sun, 27 Jul 2003 20:58:15 GMT (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h6RKwE5H066215; Sun, 27 Jul 2003 22:58:15 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Diomidis Spinellis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 27 Jul 2003 23:39:36 +0300." <3F243888.784795AC@aueb.gr> Date: Sun, 27 Jul 2003 22:58:14 +0200 Message-ID: <66214.1059339494@critter.freebsd.dk> cc: Alexander Leidinger cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2003 20:58:20 -0000 In message <3F243888.784795AC@aueb.gr>, Diomidis Spinellis writes: >Poul-Henning Kamp wrote: >> I personally don't want to have to express the same ting multiple >> times, once for the compiler and once for each interested tool is >> N-1 times too many. > >There are often hidden opportunities to avoid this problem. As an >example, our section 2 manual pages document the error codes of each >system call using the .Er macro. I find this type of documentation >extremely valuable; when I get a strange error from a system call I can >grep for the errno value in /sys to see what is going on. The lists are >not complete; I have in the last year corrected two manual pages where a >given return code was missing. I could write a tool to follow the call >graph, locate all "errno = " assignments for each function call, and >compare them against the corresponding manual page. As I see it, the >main obstacle is the various vtables that make the static establishment >of the call graph a lot more difficult. This is exactly the sort of "small tool" (except I have no idea just how "small" or not "small" it is :-) I like. I don't mind us having a convention or style(9) rule which says that error variables are called either "error" or "errno" if this means we can have a tool which helps us keep this particularly inwieldy part of our API under some sort of control. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.