C++ access specifiers are binaries????

public/protected/private are tools to prevent yourself from shooting yourself in the foot, not "anti-hack" tools. You want to see an easy way to break it?



As far as I know, the results of this code are officially "undefined" (something to do with POD types may apply, I don't know for certain). That said, I'd be suprised if the program didn't print out "21" and end with pretty much any compiler.

Accessing a object in two different translation units using two different class definitions had undefined behavior. As such, saying one compilers definition being more correct than anothers is meaningless.

That being said, it's really meaningless to be trying to test your compilers level of protection against bypassing access restrictions. To quote Stroustrup himself "The C++ language access control mechanisms provide protection against accident - not against fraud". There are large number of ways to access a private or protected member without using different definitions in different translation units.

Sorry I'm not asking about a way to hack a predefined class. I want to make sure is it a compiler feature in MS VC++ that it has more solid protection and integration with language semantics, or is it a result of undefined behaviour and I should not count on that?

And if so how should I PREVENT such hacking?

Quote:

Original post by WISMAK Sorry I'm not asking about a way to hack a predefined class. I want to make sure is it a compiler feature in MS VC++ that it has more solid protection and integration with language semantics, or is it a result of undefined behaviour and I should not count on that?

Not really. It's a little more tricky in MSVC++, because of the way it uses import libraries, but it's by no means impossible, nor even particularly hard.

Quote:

And if so how should I PREVENT such hacking?

You can't. They're running the software on THEIR processor, after all....the data's right there.

You'd have to intentionally keep two seperate definitions of a class in order to be able to accidentally shoot yourself in the foot with this, and you've got bigger issues than this if you're doing that.

Here's the relevant questions with regards to this "feature":

Q1) Will it prevent me from accidentally shooting myself in the foot?
A1) Possibly, but I think you're more likely to be struck by lightning than be helped by this. Implementing this feature is a waste of time (my opinion).

Q2) Will it prevent me from intentionally shooting myself in the foot?
A2) No.

Q3) Will it prevent someone else from shooting myself in the foot?
A3) No.

Neither behavior is more "accurate", this "feature" will neither help you program or debug (make the platform "stronger"), nor will it protect your code from being hacked (make the platform "more secure").

I'm not shooting myself and never intend to do so.

I'm asking for god sake about if it's a feature in MS VC++ or is it something results as an undefined behaviour. geeze.

When a class declaration is compiled each attribute and method belonging to the class has it's name mangled....

class test {    int someval;};

The compiler turns someval into something that looks like "??test@someval@i@@aexx". If you change the access qualifier from public to private the mangaled name (signature) of that attribute also changes. If you compile the dll with one header then compile an application with another header the symbol cannot be resolved at link time (because it's CHANGED).

Access qualifiers are applied at compile time (and link time due to mangled name signatures) NOT at runtime.


edit: the above applies to class names, method names, and static members. data members are offest from the pointer of an instantiated object.

Quote:

Original post by WISMAK I'm asking for god sake about if it's a feature in MS VC++ or is it something results as an undefined behaviour. geeze.

It's simply a difference between the compilers, not a bug, not a feature, just a difference. It dosn't help make the platform more secure nor stronger. That's what I'm trying to get at.

Would I leave the behavior as is for the Microsoft Compiler? Sure, don't fix what ain't broke.
Would I leave the behavior as is for the GNU Compiler Collection? Sure, don't fix what ain't broke.
Would I leave the spelling of my name as it is? Sure, don't fix what ain't broke.

I was simply trying to illustrate and provide sustinance to this opinion. If that offends you, well, I just hope you arn't planning to become a scientist. Or a polititian. Or a philosopher. Or religious. Or anything else that might involve trying to back up one's opinions/beliefs, or dealing with people who care to do the same.

-Mike

No it does not offend me at all, but all the answers are totally irrelevant to the question.

In my opinion it's a very strong MS Visual C++ feature and it's not about name mangling.
It's about binary level protection mechanism which should be part of the standard.

the responses are relevant, and it is not a feature. it is coincidence, and should not be relied on.

the general idea is that when you mark something as private or protected, it is so other programmers get a compile error if they try to directly access those private/protected members. if they deliberately circumvent those safety measures, it is their own damn fault when their program breaks. as someone who wants to publish their code/library/whatever, why should you care if someone goes out of their way to use it incorrectly and screws themself over?

Quote:

Original post by WISMAK In my opinion it's a very strong MS Visual C++ feature and it's not about name mangling.

Read my post from before. This is an easy mechanism to hack through. IT IS NOT INTENDED FOR SECURITY.

Quote:

It's about binary level protection mechanism which should be part of the standard.

C++ access protection is NOT INTENDED FOR SECURITY.

Quote:

Original post by WISMAK No it does not offend me at all, but all the answers are totally irrelevant to the question. In my opinion it's a very strong MS Visual C++ feature and it's not about name mangling. It's about binary level protection mechanism which should be part of the standard.

1) The answers are indeed relevant, although you are apparently unable to see that due to your own overbearing opinion which blinds you to those of others. You state yours, I state mine, you then appear to get huffy.

2) Your opinion that it's a very strong feature seems to center around the fact that you consider it a "protection mechanism". Protection from WHAT, may I ask? I'm asking you to clarify, because I explained how it dosn't protect you from yourself, nor does it protect you or your data from others, and you've deemed both these points to be irrelevant. These are the only things that spring to mind, so I'm left drawing a blank.

3) It most certainly should not be part of "the standard", regardless of wheither or not it's a strong feature. The last thing we need to do is to bog down the standard with forced features when the standard itself STILL hasn't been completely implemented on industry standard compilers (extern templates anyone?).

What about common binary languages, how is a language with no concept of a private/protected/public scope supposed to know which symbol to link against when there's 3+ different identifiers that it MIGHT link to? GCC supports more languages than Microsoft's compilers, placing such arbitrary requirements could break otherwise working systems.

Okay okay we're not fighting here! calm down!

What if there's a supposedly privated variable in the class which I don't want any client to access it's content directly without using the specified restricted get*** memebr functions because if they were able they could hack into the library and do good things from their perspectives not mine or even be able to know working internals of the library.

Design patterns? May solve the problem. But Finding that FEATURE in the great compiler of the great company is something awsome and solves my problem.

Quote:

Original post by WISMAK Design patterns? May solve the problem. But Finding that FEATURE in the great compiler of the great company is something awsome and solves my problem.

Alright, I'm going to say this in boldface. MICROSOFT VISUAL C++ DOES NOT HAVE ANY FEATURE WHICH PROTECTS PRIVATE MEMBER VARIABLES IN DLL CLASSES FROM BEING ACCESSED BY ATTACKERS. Does not have it. If you release a DLL with a class which has a private member variable, I can write a program which will access that private member variable. There is NO SECURITY BEING OFFERED. If you need the private member to remain private, THIS WILL NOT HELP YOU. It DOES NOT DO WHAT YOU THINK IT DOES.

Got it? [smile]

^^^^ me, silly thing logged me out :( ^^^^
evil_program_of_doom.cc should include evil_program_of_doom.hh

Further, I am quite calm. Confused by you, but calm nonetheless. I've only posted fact, request for clarification on what we're talking about soas to address your misbelief with regards to this otherwise irrelevant compiler implementation detail, and my beliefs drawn from your defensive nature and seeming unwillingness to attempt to understand what's being said when it seems to conflict with what you think you know, which I state only to attempt to confirm, deny, or make yourself aware of such a possibility.

Besides, today was a beautiful day, not a cloud in the sky, nice and hot, and accompanied by tasty doses of caffeine. How could I not be calm? Well, except for the fact that I have no plunger and my toilet has clogged badly after shitting [lol]... (I suppose I should go out and buy one tomorrow... speaking of which, what does one usually do after plunging a shit filled toilet? Wash off said plunger with a hose?)

[Edited by - MaulingMonkey on July 19, 2005 12:40:58 AM]

And what does this have to do with my question?

Is there any option in GNU gcc or icc that forces memebr access protection to be binary like in Visual C++?

Thanks.

Visual C++ doesn't "force access protection to be binary." Most likely what happened in your case is that the difference in class definition caused name mangling to be different which made it seem like MSVC had some sort of binary protection. But it doesn't. You're trying to duplicate non existant functionality.