From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.1 Date: Thu, 12 Dec 2019 22:43:15 +0300 From: Andrey Savchenko To: ALT Linux Team development discussions Message-Id: <20191212224315.b5b14736ba94b86fa85a830c@altlinux.org> In-Reply-To: References: <20191206133647.dculnmwkd3yf2wjp@titan.localdomain> <20191206153655.86334-1-darktemplar@altlinux.org> <20191208232108.GC30742@altlinux.org> <20191210000737.GD15867@altlinux.org> <1ee850d3-9ebd-ae95-2665-f5ba7fb86ad4@altlinux.org> <20191210102009.GB22650@altlinux.org> <20191210222017.GA31774@altlinux.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Thu__12_Dec_2019_22_43_15_+0300_8+aX4lkjSice=VT1" Subject: Re: [devel] [PATCH for apt 2/2 v2] Fix pointer arithmetics X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2019 19:43:25 -0000 Archived-At: List-Archive: List-Post: --Signature=_Thu__12_Dec_2019_22_43_15_+0300_8+aX4lkjSice=VT1 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 11 Dec 2019 10:50:22 +0300 Aleksei Nikiforov wrote: > 11.12.2019 1:20, Dmitry V. Levin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Tue, Dec 10, 2019 at 01:58:17PM +0300, Aleksei Nikiforov wrote: > >> 10.12.2019 13:20, Dmitry V. Levin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>> On Tue, Dec 10, 2019 at 11:18:06AM +0300, Aleksei Nikiforov wrote: > >>>> 10.12.2019 3:07, Dmitry V. Levin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>>> On Mon, Dec 09, 2019 at 10:08:42AM +0300, Aleksei Nikiforov wrote: > >>>>>> 09.12.2019 2:21, Dmitry V. Levin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>>>>> On Fri, Dec 06, 2019 at 06:36:55PM +0300, Aleksei Nikiforov wrote: > >>>>>>> [...] > >>>>>>>> @@ -85,11 +87,11 @@ class pkgCache::PkgIterator > >>>>>>>> inline unsigned long long Index() const {return Pkg - Ow= ner->PkgP;}; > >>>>>>>> OkState State() const; > >>>>>>>> =20 > >>>>>>>> - void ReMap(void const * const oldMap, void const * const new= Map) > >>>>>>>> + void ReMap(void *oldMap, void *newMap) > >>>>>>> > >>>>>>> Is there any particular reason for stripping const here and in ot= her > >>>>>>> similar places? > >>>>>> > >>>>>> Yes, it's needed due to issues emerging from mixing const and non-= const > >>>>>> pointers with new and allegedly more proper way of calculating reb= ased > >>>>>> pointers. > >>>>> > >>>>> Sorry, I don't find this argument convincing. > >>>>> I have experienced no const issues in my version of this fix. > >>>> > >>>> Your version is using C-style casts in C++ code. Of course, I could = use > >>>> C-style casts or const_cast-s too to work around const correctness > >>>> issues (i.e. to just hide these issues), and it'd work like your > >>>> version. But I'd like to remind you that APT is C++ project, not a C > >>>> project. What might be ok for C is sometimes a dirty ugly hack in mo= dern > >>>> C++. > >>> > >>> Sorry, I don't share you point of view on this matter. > >>> Being a C++ project allows you to use C++ constructs, that's true, > >>> but why do you think it prevents you from using C constructs when > >>> appropriate? > >> > >> I didn't say that something prevents from using C constructs when > >> appropriate. I'm saying that these constructs are not appropriate here. > >=20 > > Why do you think they are not appropriate here? > >=20 >=20 > In good C++ code there is no place for const_cast. This statement is ungrounded. > Maybe there are some=20 > exceptions to it, but they have to be justified. It doesn't matter that=20 > you are hiding it behind C-style cast. Please read some good book on C++ like [1] or at least the official reference manual [2]. Aside from C-style cast C++ supports four casts (in their safety order, the safest first): const_cast static_cast dynamic_cast reinterpret_cast One can see their preference order base on how explicit C-style cast is being intrepreted by the C++ compiler [3]. So actually the reinterpret_cast should be avoided when it is possible to use more strict casts, because reinterpret_cast disables all safety checks aside from constness and volatileness one. [1] Stanley B. Lippman, Josee Lajoie, C++ Primer. Chapter 4.14 Types Conversion. [2] https://en.cppreference.com [3] https://en.cppreference.com/w/cpp/language/explicit_cast Best regards, Andrew Savchenko --Signature=_Thu__12_Dec_2019_22_43_15_+0300_8+aX4lkjSice=VT1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE63ZIHsdeM+1XgNer9lNaM7oe5I0FAl3ymFMACgkQ9lNaM7oe 5I1aaBAAh3TLkFvXr/s/Mmyt4ECoHXbcGVH00RQed7OaF3u4M1r+WYT+iDyFJtyV qIknNvyFQwyO6BX54hRFNdyJfbvLLm9FlFUvqyxQQeW6RO4p2H33xQCa+FpabFfi RkrZ/Qtyr9EsdQzaiviMyVQKKCC3Uu6jr5lSX0Azq7szYlUtosPGZ+kIXK7soRQ8 KiugyMb9OnlEJC8PljLoyBNeAQyaW30SGbRAsmdCL/tMVx69NAR/PsptlWcXHH3+ gycXJkGko9gCMV8Z0ubehuCw1vf5wDRY81wcIPIjS9ifwJrDlCAmivfJFE5KbMUW KVV7K3F2FepGoCUxmt07WQpsSx9BibnfqctqBjsEuhYsJB8fDgeHl9bccDuaYQv9 LAQp3OAS6xwUkM//GWEWUp905Bo7U4gXdIM6BerX52/FiWPXTs/mVF6U4ENP+Kr/ /JXAoF19oPDpUqZ+X5hv7nkAFZsY8DxXNnFOmtjpH3ow0F7baUPFWRsAzrSDjwPG F7a3evGjWVwYppAtVKVZmVtSjqxPIoR7dJrajzwzn1ttw19sImrrdn//IFiQf4AB C9TCx+khZU5ZTwDAeYDwQGei3lHWOWNJiO/NzQcgH6sc1IyOIxzFrpYi2molYO7p BXXOXHtIFYxWienCLYC1NoF/jPnRnUdMZzkDOBJm/LDZ7dN38ts= =KfZ6 -----END PGP SIGNATURE----- --Signature=_Thu__12_Dec_2019_22_43_15_+0300_8+aX4lkjSice=VT1--