220 25691 <4a4c2fe7-397e-4ca0-bdbe-04e77f075cee@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: About subverting access rights Date: Thu, 28 Apr 2016 11:48:44 -0700 (PDT) Lines: 409 Approved: news@gmane.org Message-ID: <4a4c2fe7-397e-4ca0-bdbe-04e77f075cee@isocpp.org> References: <20e81af7-4506-4408-b73a-58371434bd40@isocpp.org> <20160426021923.4898897.72532.10230@gmail.com> <472a15d5-4591-4bd1-9233-01c8550c5c6f@isocpp.org> <2257513b-f4d8-44ed-8ccf-1da1ff1e4ac5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6238_147938797.1461869324789" X-Trace: ger.gmane.org 1461869332 30541 80.91.229.3 (28 Apr 2016 18:48:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Apr 2016 18:48:52 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBDVWRG4QKGQEMLNR4TY@isocpp.org Thu Apr 28 20:48:48 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1avqzX-00079W-SC for gclcip-std-proposals@m.gmane.org; Thu, 28 Apr 2016 20:48:48 +0200 Original-Received: by mail-oi0-f69.google.com with SMTP id y69sf165568379oif.0 for ; Thu, 28 Apr 2016 11:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=NgrVSS4zeoQXMAUr6OkIlQ1a/At84Px46iTaET2fS5o=; b=w/cui7jR/ZlJMZkx6WZeexcFMobE64tdE1uyVg3770cd+oMTDhwm3SZzZwBiUP7El3 EtJhE3is/AJQ51WYkr1hEb/gC8cPfCzt29l9Rj3yyJ6Zbl7olBx6Bte8518eX4LgCdtU tNDD7Sx3bOTTz3WRs6VTQw4BQfsRm0Y6r89vpX+CNcesaIcm+oCRhAcXU5U0nUxyA34m KaLyDw4IAZtYCv3DZ6FHSyUUlpaUJQbDkersWiK1MCj8jHKLh0q4EsZrxy5zUE/cl2lW BdDj+6ELR/hVMCW99S+mf+u0raleDx/wFi4E0JvpF3J9Jl4njuDDdkJxkak3WpAjKA2t wJFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=NgrVSS4zeoQXMAUr6OkIlQ1a/At84Px46iTaET2fS5o=; b=gb/vd6fV/ZhxQGTzt1aPCKZPF1dXEN2fUXuvPa4QRwoYsZtJ6C5fJ8ekOg/6cBg9Fg XgZJ7puP5fDeRGQINUeZx14y9RGosEaspEzAnp6eogR/Axr5Yr6rAc3CrnjWntyv459K yGqTZwheEbEnmMIc4ZvV5afWtJ55KP5XkLUHbLyHHvnVf3kZJURgvkYQXHAW0klT2Wv2 SpQGCK6jxyMG70UJBS9He+/sLBnWdvKxhAOWtdmPwwNvo1CDoSj8GV+lZ/TxUSGH2dQp B49ITc9bTr1ukg/+gwzeR5adwp44mbra8FsNXdB+bEWQdUMXgKIq6OKpm67I6RUR1FTV ZDnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=NgrVSS4zeoQXMAUr6OkIlQ1a/At84Px46iTaET2fS5o=; b=i7HDwqWjtzyfp6GNzVmeksnqjQpD0Xc3Vih6UrktAQsFO4TQKYY2XVe0gDW2dgoSWl IIjTgdk8Cuutar97hQxyp3hURWyZzUtuL8rFbDO8pbJqUHPPfRnG8VyBj25uI58bTrhB /1clnP09UiJLyEXE67ON1Mc14UVlJS0ct5+/58BrgL4omeqx4LNq1yQo61m1G7SRHnhD vXh8rImhAvPiAE8oyrEpvOSlUNS8ITKSo34CqkDOdv5Avmz1g+JK3qDi4kMOWa2QCNb+ gvY2QsfgpdAgX+6dlGPC5ktNuB+K8eLNtk852e9WADWZ7QmKOPPzELgqygPW87Pm2os1 P2IA== X-Gm-Message-State: AOPr4FXJn/Y3fQWqPUn8twT5FhBoUr2+uMAJ2bH+ZZwC/seNQbsypUbWZgXUwtSHy9SzZw== X-Received: by 10.50.29.77 with SMTP id i13mr15308585igh.11.1461869326841; Thu, 28 Apr 2016 11:48:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.128.135 with SMTP id no7ls17085igb.41.canary; Thu, 28 Apr 2016 11:48:45 -0700 (PDT) X-Received: by 10.50.30.38 with SMTP id p6mr742781igh.10.1461869325906; Thu, 28 Apr 2016 11:48:45 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:25691 Archived-At: ------=_Part_6238_147938797.1461869324789 Content-Type: multipart/alternative; boundary="----=_Part_6239_456387032.1461869324789" ------=_Part_6239_456387032.1461869324789 Content-Type: text/plain; charset=UTF-8 On Thursday, April 28, 2016 at 1:35:11 AM UTC-4, Ricardo Andrade wrote: > > Let me summarize the whole point of starting this discussion... > - We cannot prevent people from circumventing encapsulation. > It depends on what you mean by that. As a practical matter on real implementations, you are correct. As a matter of standard-sanctioned behavior, we very much can. Something can be illegal, yet people will still do it. That fact alone does not mean the law should be changed to permit it. - Reflection is likely to add yet another way to do it. > Quite likely. - This will be the first "standard" way for this purpose. > Yes. - It has the benefit of being easy to spot in the code (currently as > get_all_data_members in P0194R0). > Kinda. Yes, you can spot that someone is calling `get_all_data_members`, but knowing exactly which objects this is being employed upon will be much more difficult. Especially in a deeply-nested template function. - But there's a chance it will be costly in terms of compile time and > complexity. > .... I suppose that's possible. I mean, I don't know of a way to iterate through the unknown privates of a type at compile time that *wouldn't* involve template metaprogramming. But it's possible you could craft such a mechanism, and therefore it would be faster at compile time than reflection. - People may end up not using it and sticking with the old "non-standard" > ways > That's a good thing. We do not want people to use reflection for the specific purpose of violating access controls. - In the other hand, if people do use it, reflection gets the bad > reputation of being "the corner of the language reserved for evil" - as it > does in the other languages. > Wait, what? How does that logically follow? You just claimed that people won't use reflection to violate access controls because it's slow. If that's true, why would it gain this bad reputation you speak of? So either this statement or the one before it is false. Or both. But they can't both be true. Oh, and do you have any basis for the claim that reflection in other languages is seen as "the corner of the language reserved for evil"? I was under the impression that reflection in C# was used fairly heavily by XAML, for example. I did a quick search for "C# reflection evil", and the most I got were warnings about the *performance* of reflecting, not the concept itself. So it seems that in other languages, there is not such a rash of people using reflection to violate encapsulation that people consider reflection a priori perfidious. > - Now that you mentioned accidents, get_all_data_members vs. > get_data_members don't contribute much to prevent those, but there's still > time to work that out - I'll mentioned that to the author of P0194R0. > > That said, comes the question: > Wouldn't be better to provide a "reinterpret_cast"-like mechanism (or > anything else) just for this purpose? > No. We don't want to regularize bad behavior. And violating encapsulation is *always* bad behavior. FYI: `reinterpret_cast` is not regularizing bad behavior; it's simply a tool that can be easily abused. - Reflection would be the "mechanism to list declarations and infer their > characteristics", the way to use them that's up to you. > That's not what reflection is. Reflection also allows you to call methods, access data members, and so forth. And in any case, if reflection allows violation of access controls, it must still do so even with whatever other method you want to add. - It would be easy and obvious to find such violations in the code. Then > violators can be caught. > Only if they are used consistently. - If a proposed solution has equivalent performance of the hacky > alternatives but it states clearly the intentions, people will prefer to > use it (or they would be so ashamed of having such ideas and avoid it). > Only if they are writing new code. Old code isn't automatically going to be changed. - A dedicated language solution is more likely to find a better balance for > safety, freedom and clarity than something buried deep down in reflection. > Reflection does not allow private access because it is attempting to improve "freedom" or "clarity" or whatever. It's doing it because reflection needs to in order to be a proper tool. Also, your statement presupposes that the current "balance" is problematic. It isn't. Just because some people break laws doesn't make those laws wrong. I bet there are several ideas that could work out but first we need to go > over this feeling that people will use whatever is proposed everyday and > break everything. > Sanctioning the violation of encapsulation is, and of a right ought to be, a hard sell. Encapsulation should be a binary concept. Either it is accessible without perfidy or it is not. Saying that it isn't accessible unless you do this slightly inconvenient thing means that it is *accessible*. And therefore not encapsulated. > People stay away from "reinterpret_cast" already > That's because they use C-style casts. > because is too 'dark' and bet people would think twice before using > something called "violate_access_cast". > > That's it. > > On Wed, Apr 27, 2016 at 4:13 PM, Peter Koch Larsen > wrote: > >> I do not understand all this fuzz about subversion of access rights. >> Let us face it: >> *) The purpose of access privileges is to protect the programmer from >> doing something stupid, such as using an >> object in a way it way not designed to be used. It has never been >> the purpose of access privileges to e.g. protect >> a system from an intruder or something in that direction. >> *) There are already ways in C++ to get access to the private parts of >> an object. Having one more way to do so is not >> a problem. >> > Neither of those is a justification for doing what you suggest. > That being said, I believe that getting the access should be >> difficult: it should be blatantly clear that you are doing >> something dangerous - just as it is with e.g. reinterpret_cast. > > `reinterpret_cast` is not "difficult". Also, >> I fail to see the advantage of having this access. >> I am in the camp that believes that e.g. serialization is perfectly >> feasible without knowledge of the inner details about >> how such a class is defined. >> > So... what you're telling me is that you want to write crappy, fragile code. You want to violate standard rules about data hiding based on a premise that has been *proven faulty* (all it takes is one counter-example and I provided it). Also, even if we allowed you private access, you still couldn't properly construct such objects, because the only way to start the lifetime of an object in a piece of memory is to use placement `new`. Which must call a constructor. So your prospective unintrusive serialization library still has to use extra-standard methods (an illegal cast to `T*` or `T&` at some point). You are basically proving exactly why we *shouldn't* let you do what you want. Because if you give people a standard-sanctioned tool for breaking encapsulation, people like you will *misuse it*. Since you have clearly and unequivocally stated your intent to do so. Really, the only thing you've convinced me of is that reflection should have *additional* controls, for the sole purpose of preventing people like you from writing the library you want to write. That there should be some mechanism to prevent `get_all_data_members` and its ilk from working unless you are in code that has private access already. Perhaps the MetaObject type generated for reflection purposes should have Public, Protected, and Private versions. If you're in code with private access to the class and you get a MetaObject for it, then you get the Private MetaObject type. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4a4c2fe7-397e-4ca0-bdbe-04e77f075cee%40isocpp.org. ------=_Part_6239_456387032.1461869324789 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, April 28, 2016 at 1:35:11 AM UTC-4, Ricardo A= ndrade wrote:
= Let me summarize the whole point of starting this discussion...
- We ca= nnot prevent people from circumventing encapsulation.

It depends on what you mean by that. As a practical matter on r= eal implementations, you are correct.

As a matter of standard-sancti= oned behavior, we very much can.

Something can be illegal, yet peopl= e will still do it. That fact alone does not mean the law should be changed= to permit it.

- Reflection is likely to add yet another way to do it.=

Quite likely.

- This will be the fir= st "standard" way for this purpose.
=
Yes.

- It has the benefit of being easy to spot in the code (curre= ntly as get_all_data_members in P0194R0).

= Kinda. Yes, you can spot that someone is calling `get_all_data_members`, bu= t knowing exactly which objects this is being employed upon will be much mo= re difficult. Especially in a deeply-nested template function.

- But t= here's a chance it will be costly in terms of compile time and complexi= ty.

... I suppose that's possible. I m= ean, I don't know of a way to iterate through the unknown privates of a= type at compile time that wouldn't involve template metaprogram= ming. But it's possible you could craft such a mechanism, and therefore= it would be faster at compile time than reflection.

- People may end = up not using it and sticking with the old "non-standard" ways

That's a good thing. We do not want peopl= e to use reflection for the specific purpose of violating access controls.<= br>
=
- In the other hand, if people do use it, reflection gets the bad repu= tation of being "the corner of the language reserved for evil" - = as it does in the other languages.

Wait, w= hat? How does that logically follow? You just claimed that people won't= use reflection to violate access controls because it's slow. If that&#= 39;s true, why would it gain this bad reputation you speak of?

So ei= ther this statement or the one before it is false. Or both. But they can= 9;t both be true.

Oh, and do you have any basis for the c= laim that reflection in other languages is seen as "the corner of the = language reserved for evil"? I was under the impression that reflectio= n in C# was used fairly heavily by XAML, for example. I did a quick search = for "C# reflection evil", and the most I got were warnings about = the performance of reflecting, not the concept itself.

So it = seems that in other languages, there is not such a rash of people using ref= lection to violate encapsulation that people consider reflection a priori p= erfidious.
=C2=A0
- Now that you mentioned accidents, get_all_data_members = vs. get_data_members don't contribute much to prevent those, but there&= #39;s still time to work that out - I'll mentioned that to the author o= f P0194R0.

That said, comes the question:
Wouldn't be better to provide a "reinterpret_cast"-like mec= hanism (or anything else) just for this purpose?

No. We don't want to regularize bad behavior. And violating enca= psulation is always bad behavior.

FYI: `reinterpret_cast` is = not regularizing bad behavior; it's simply a tool that can be easily ab= used.

- Reflection would be the "mechanism to list dec= larations and infer their characteristics", the way to use them that&#= 39;s up to you.

That's not what reflec= tion is. Reflection also allows you to call methods, access data members, a= nd so forth. And in any case, if reflection allows violation of access cont= rols, it must still do so even with whatever other method you want to add.<= br>
=
- It would be easy and obvious to find such violations in the code. Th= en violators can be caught.

Only if they a= re used consistently.

- If a proposed solution has equivalent perform= ance of the hacky alternatives but it states clearly the intentions, people= will prefer to use it (or they would be so ashamed of having such ideas an= d avoid it).

Only if they are writing new = code. Old code isn't automatically going to be changed.

- A dedica= ted language solution is more likely to find a better balance for safety, f= reedom and clarity than something buried deep down in reflection.

Reflection does not allow private access because it= is attempting to improve "freedom" or "clarity" or wha= tever. It's doing it because reflection needs to in order to be a prope= r tool.

Also, your statement presupposes that the current "bala= nce" is problematic. It isn't. Just because some people break laws= doesn't make those laws wrong.

I bet there are several= ideas that could work out but first we need to go over this feeling that p= eople will use whatever is proposed everyday and break everything.

Sanctioning the violation of encapsulation is, and= of a right ought to be, a hard sell.

Encapsulation should be a bina= ry concept. Either it is accessible without perfidy or it is not. Saying th= at it isn't accessible unless you do this slightly inconvenient thing m= eans that it is accessible. And therefore not encapsulated.
=C2= =A0
People stay away from "reinterpret_cast" already

That's because they use C-style casts.
=C2=A0

So... what you're telling me is that you want to write = crappy, fragile code. You want to violate standard rules about data hiding = based on a premise that has been proven faulty (all it takes is one = counter-example and I provided it). Also, even if we allowed you private ac= cess, you still couldn't properly construct such objects, because the o= nly way to start the lifetime of an object in a piece of memory is to use p= lacement `new`. Which must call a constructor. So your prospective unintrus= ive serialization library still has to use extra-standard methods (an illeg= al cast to `T*` or `T&` at some point).

You are basically provin= g exactly why we shouldn't let you do what you want. Because if = you give people a standard-sanctioned tool for breaking encapsulation, peop= le like you will misuse it. Since you have clearly and unequivocally= stated your intent to do so.

Really, the only thing you've conv= inced me of is that reflection should have additional controls, for = the sole purpose of preventing people like you from writing the library you= want to write. That there should be some mechanism to prevent `get_all_dat= a_members` and its ilk from working unless you are in code that has private= access already. Perhaps the MetaObject type generated for reflection purpo= ses should have Public, Protected, and Private versions. If you're in c= ode with private access to the class and you get a MetaObject for it, then = you get the Private MetaObject type.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/4a4c2fe7-397e-4ca0-bdbe-04e77f075cee= %40isocpp.org.
------=_Part_6239_456387032.1461869324789-- ------=_Part_6238_147938797.1461869324789-- .