pon., 17 lut 2025 o 14:24 Amit <amitchoudhary0523_at_[hidden]> napisał(a):
>
>
>> There is a difference in making questions and claiming in the first
>> line of the email:
>> "C++ language has a big security hole".
>
>
> I thought it was a security hole and I said that but I didn't target anyone personally. You could have explained that this is not true. Even then if I am talking about the same thing in all my mails then that would have been a problem. If I wanted to keep creating problems that why would I have agreed.
>

You do not need to "target" any one, this is similar to claiming that
"Earth is flat" and showing "proofs" of this.
You will get exactly the same reaction. Simply `private:` and
"security" have no meaning in one sentence for C++.
If you want another example, it could sign on the door "staff only" in
a restaurant. Nobody will claim this is "security" and prevent
anyone from entering these doors. its only goal is to prevent confused
clients not wander into places where they should not be.
And this is exactly the same role `private:` does in C++.

>>
>> As others point out, C++ have lot of holes but this is not one of them.
>>
>> Claims like this show the very surface level of the problem domain,
>> this is why people react so.
>
>
> So, why do people have to react in a negative way? Reacting in a negative way doesn't make sense. You have the option of counteracting my statement in detail.
>

Because this is not stackoverflow, some level of understanding of C++
is required as this mailing list of standarazion not usage of C++.


>
>>
>> >
>> >> Besides, even if I want to have "secure" `private:` how would you like
>> >> to archive it?
>> >
>> >
>> >
>> > If I were to design an object oriented language then I would have designed it like Java. At least, I wouldn't have provided any pointers.
>> >
>>
>> Are you aware that reflection allows access to private data too?
>> Same with C#, you are free to modify internal objects.
>
>
>
> The language itself allows that. So, does this mean that C++ is allowing the same thing through pointers? I didn't read about this anywhere
>

Do "not allow", this is UB, this means it's outside of standard and
what happens is CPU specific. As this can't be done by accident
I do not see the point in wasting time to prevent this.

Besides, you did not answer how you would want to prevent this in the
first place?
There is no way to prevent accessing some members without a heavy cost penalty.

>>
>> >>
>> >> besides, if I'm "hacker" and want to corrupt my own code I can write
>> >> code like `*(int*)nullptr = 1`
>> >> or `system("format C:/");`, I do not need to abuse `private` to do this.
>> >
>> >
>> >
>> > I didn't talk about hacking my own code.
>> >
>>
>> But it is, when you compile code its yours, even if someone else
>> writes this as a library.
>> You can even edit it as its `txt` file.
>
>
>
> From this point of view, all languages are safe then.
>
> Then this world should not talk about which language is safe and which isn't.

But you do not understand what "safe" means in this context.
"safe" from external factors, not your own actions.
NO program language try be "safe" in your meaning.
Lets use Rust for this, it has an `unsafe` context where
you can make 100% the same code with pointers like you had in your
first email that bypass access control.
And this is considered one of most safest languages today.



Beside if all this discussion is simply X Y problem, and your
whole goal is prevent other programs to access your library code state then
do not leak pointers but use `int` handlers that will
be exposed to end users of your code.

But this still could not prevent anyone from accessing your data
as they could alter linker scripts to expose root pointers from
your object files.

>
> Regards,
> Amit
>