C++ access specifiers are binaries????
Author
Hi
I created a simple class for testing purposes to see how C++ is serious about memebr access specifiers.
Inside the DLL module a simple class with a private/protected member.
Inside the client EXE program I used the same header for class definition with a change to the protected/private member to public so that I thought I could access it breaking the C++ protection mechanism.
Using Visual C++ toolkit 2003 the program still cannot resolve the public symbol in the class since it's declared in the DLL as protected/private. This is a good thing; however, it's not true for GCC and Intel C++ under Linux.
Which behaviour is more accurate and is it possible to do the same under the Linux? It seems that MS has stronger programming platforma nd more secure.
Thanks for your help in advance.
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.
#include <iostream>using namespace std;class foo {private: int variable;public: void set_variable( int v ) { variable = v; }};class bar {public: int variable;};int main() { foo f; f.set_variable( 21 ); //f.variable is protected, right? //wrong: std::cout << ((bar *)&f)->variable << std::endl;}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.
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.
Author
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?
And if so how should I PREVENT such hacking?
Quote:Original post by WISMAKNot 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.
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?
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").
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").
Author
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.
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....
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.
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
Author
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
