From owner-svn-src-all@freebsd.org Tue Aug 11 08:55:34 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1434599D08F; Tue, 11 Aug 2015 08:55:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id CCAEF830; Tue, 11 Aug 2015 08:55:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id CB6A57818B5; Tue, 11 Aug 2015 18:55:26 +1000 (AEST) Date: Tue, 11 Aug 2015 18:55:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Xin Li cc: Ed Schouten , d@delphij.net, Xin LI , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r286601 - head/usr.bin/patch In-Reply-To: <55C98F8B.4020103@delphij.net> Message-ID: <20150811182726.I2033@besplex.bde.org> References: <201508102131.t7ALVo5J050735@repo.freebsd.org> <55C931CE.3030806@delphij.net> <55C98F8B.4020103@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=XMDNMlVE c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=SWg00rOMAAAA:8 a=Y93YNYS4GYCrfHJej2oA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 08:55:34 -0000 On Mon, 10 Aug 2015, Xin Li wrote: > On 8/10/15 22:51, Ed Schouten wrote: >> 2015-08-11 1:20 GMT+02:00 Xin Li : >>> Do you have a better solution for this? No, this is not ideal >>> but I didn't find a better alternative (or maybe I have missed >>> something obvious?) >>> >>> I think with the current POSIX definition of the interface, we >>> have only two options: either strdup() or cast away const (I'd >>> rather hide this kind of uglyness in the library), no? >> >> Casting const away should be all right in this case. It is the Standard way. > Committed as r286617, please let me know if you want other > changes, etc. > > Perhaps we should convert the tree over time to use __DECONST instead > then? Gak!. I use rmrf on code with __DECONST in it. The misimplementation of __DECONST only "works" because -Wcast-qual is too broken to detect removal of qualifiers by casting a pointer to an integer. Casting a pointer to an integer is much less safe than casting away only a qualifer for a pointer, but both are Standard, so they work unless the compiler is directed to be nonstandard using -Wcast-qual -Werror. Compilers should know about the language defects that make it impossible to declare functions like execv() with the correct number of const's and turn off -Wcast-qual warnings for these functions. strchr() is another function that needs special. It can take a pointer const char and return a related pointer with the const qualifier removed (subtract an offset to get the original pointer with its const qualifier removed). The warning about this from -Wcast-qual is not yet killed using __DECONST() because libc is still compiled with a low WARNS. The implementation uses a cast in the Standard way. Only the implementation would be affected by -Wcast-qual. But a flag like -Wcast-qual should direct the compiler to warn about removal of casts by abusing strchr() too. Bruce