From owner-cvs-src@FreeBSD.ORG Tue May 22 16:56:09 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D245116A46D; Tue, 22 May 2007 16:56:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8C50113C4C9; Tue, 22 May 2007 16:56:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C112917382; Tue, 22 May 2007 16:56:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l4MGuQlP013452; Tue, 22 May 2007 16:56:26 GMT (envelope-from phk@critter.freebsd.dk) To: Warner Losh From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 May 2007 10:20:45 CST." <20070522.102045.112563319.imp@bsdimp.com> Date: Tue, 22 May 2007 16:56:26 +0000 Message-ID: <13451.1179852986@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: cvs-src@freebsd.org, src-committers@freebsd.org, rwatson@freebsd.org, cvs-all@freebsd.org, bde@optusnet.com.au Subject: Re: cvs commit: src/lib/libmemstat memstat_malloc.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2007 16:56:09 -0000 In message <20070522.102045.112563319.imp@bsdimp.com>, Warner Losh writes: >> > Should know better than to use __DECONST: C programmers. > >Zen Master bde hits. You are confused. You are Dazed.--More-- >You have received enlightment. Welcome to level 34583. Actually, I'm not sure I made it. Const is a very useful construct, both for the compilers ability to generate good code and for the programmer to express his intention, but the simplicity of the const concept in C means that it is less useful than it could be, unless __DECONST and similar are (ab)used. Take a simple example: struct foo { ... }; struct foo *create_foo(args, ...); void destroy_foo(struct foo *); Nothing outside these two functions should modify, reassign or otherwise muck about with the contents of a struct foo. In an ideal world, I would have two versions of struct foo: one where all members are const and one where they are not, and compiler would realize that a cast from the R/W to the R/O variant is a safe operation, so that create_foo() could be written in terms of and return the R/O variant How to do the destroy_foo() needs a different trick, since we are not modifying the fields, we are destroying them, so the needed information here is custody information: void destroy_foo(struct foo * __custody); which tells the compiler that the pointer and what it pointed to is not valid after a call to destroy_foo(). C unfortunately lacks a syntax that can express suck subtle and non-subtle nuances and recent standardization efforts have shown little interest in offering more "intentional programming" facilities in C. Absent such progress and despite what the Zen master says, I think const is a useful concept and that the occational well-thought out use of __DECONST() can not only be fully justified but also recommended. Provided it is used to improve the expression of deliberate intent, rather than to paste over gottchas. -- 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.