From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 94a3b4b3; Fri, 15 Jul 2016 17:08:51 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1bOBHs-00075x-Ce; Sat, 16 Jul 2016 00:08:50 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1bOBHq-0000ra-Ry; Sat, 16 Jul 2016 00:08:46 +0200 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1bOBHq-0007iG-Ml; Sat, 16 Jul 2016 00:08:46 +0200 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 70b7e541; Sat, 16 Jul 2016 00:08:46 +0200 (CEST) Date: Sat, 16 Jul 2016 00:08:46 +0200 From: Ingo Schwarze To: Joerg Sonnenberger Cc: tech@mdocml.bsd.lv Subject: Re: mdocml: To remove the const qualifier from a pointer to an object Message-ID: <20160715220846.GA13283@athene.usta.de> References: <15489725859697430873.enqueue@fantadrom.bsd.lv> <20160715213103.GA7335@britannica.bec.de> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160715213103.GA7335@britannica.bec.de> User-Agent: Mutt/1.6.2 (2016-07-01) Hi Joerg, we seem to disagree here. Joerg Sonnenberger wrote on Fri, Jul 15, 2016 at 11:31:03PM +0200: > On Fri, Jul 15, 2016 at 02:33:31PM -0500, schwarze@mdocml.bsd.lv wrote: >> To remove the const qualifier from a pointer to an object - either >> because we know it is actually mutable or because we are passing >> it to a function that doesn't accept a const object but won't >> actually attempt to modify it - simply casting from (const type *) >> to (type *) is legal C and clearly expresses the intent. >> So get rid of the obfuscating UNCONST macro. >> Basic idea discussed with guenther@. > This is completely wrong and a clear regression. There is no regression. The code works fine after the change. > The macro exists The macro does not exist. Neither the C standard nor POSIX specify it or even indicate that something like that might be needed or even useful. It was a purely local quirk in one single place of the mandoc codebase. Besides, i checked with Philip Guenther, who is both an expert in C and in POSIX, that no contortions are needed here. > for two reasons: > (1) It makes auditing easier by giving something simple to look for. It makes auditing harder due to obfuscation. What a plain cast does is obvious on first sight. A macro needs to be looked up when auditing the code to understand what it does, and due to the unnecessary quadruple cast const char **" -> const void * -> intptr_t -> void * -> char * const * instead of one single cast it makes auditing even harder. I see no point in specifically auditing for casts removing const. Sure, auditing for type conversion issues is useful, but many type conversions, particularly implicit ones, are much more dangerous than const removals. Auditing for type conversion errors is very hard (think of signedness and width issues). Introducing an ugly macro to make one of the lesser problems stand out prominently doesn't help at all. > (2) The macro actually stopped -Wcast warnings. You mean, -Wcast-qual? That's not enabled by default for a reason: It's not useful in production builds. (It may occasionally be helpful when doing a one-time audit of a dubious code base to identify candidates for erroneous casts, though.) > The replacement does not. Just don't enable -Wcast-qual for compiling mandoc. I consider that option harmful because it drives developers toward obfuscation. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv