From owner-cvs-all@FreeBSD.ORG Tue May 22 19:14:02 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75C7316A475; Tue, 22 May 2007 19:14:02 +0000 (UTC) (envelope-from bde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 60FE413C45E; Tue, 22 May 2007 19:14:00 +0000 (UTC) (envelope-from bde@optusnet.com.au) Received: from besplex.bde.org (c211-30-216-190.carlnfd3.nsw.optusnet.com.au [211.30.216.190]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l4MJDj9U030164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 May 2007 05:13:47 +1000 Date: Wed, 23 May 2007 05:13:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Robert Watson In-Reply-To: <20070522130612.A28780@fledge.watson.org> Message-ID: <20070523042117.G87260@besplex.bde.org> References: <13451.1179852986@critter.freebsd.dk> <20070522130612.A28780@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, Poul-Henning Kamp , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Warner Losh Subject: Re: cvs commit: src/lib/libmemstat memstat_malloc.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 22 May 2007 19:14:02 -0000 On Tue, 22 May 2007, Robert Watson wrote: > On Tue, 22 May 2007, Poul-Henning Kamp wrote: > >> 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. Further investigation (more details in private mail) shows that the use of __DECONST() here is even worse than for pasting over gotchas. __DECONST() is being abused mainly to convert from a pointer to an unsigned long. It casts away a const qualifier almost as a side effect, but so does the old code on amd64 at least. Both __DECONST() and the old code depend on the gcc bug that -Wcast-qual is broken for casts from pointers to integers. If the change to use __DECONST() has any effect at all, then it seems to be because gcc has fixed this bug for conversions to some integer types but not to uintptr_t. > I like const, but it necessarily requires incremental deployment on a code > base. __DECONST allows use of const in new modules before dependent modules > have been converted. To pull an arbitrary example out of an arbitrary hat: > libkvm isn't const-poisoned, but libmemstat is. With the new gcc version, we > now see a warning, which is silenced by marking the transition into libkvm > with __DECONST. Again, the type mismatches have very little to do with const. libkvm requires kernel addresses to be represented as unsigned longs, while libmemstat requires kernel addresses to be represented as "void *"s or "const void *"s. Neither of these requirements is very good, and libmemstat's requirement is a regression if anything, since the kernel address space might be segmented or otherwise magic and thus unrepresentable by userland pointers. To convert between these APIs, pointers must be converted to integers, and type qualifiers are normally lost as a side effect. Bruce