A query : C++

[Chetan Raj]

Hi All,

One of my friend asked this question on C++

Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
..a files) and the linker will complain.

Can any one elaborate on this issue?

Thanks,
Chetan Raj

 

[Gianni Mariani]

Hi All,

One of my friend asked this question on C++



Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

More than likely it will work. However it is not required to work by
the standard. The standard requires that the definition of the class
remains identical in all compilation units that use it, so this is a
clear violation of that requirement. However, I don't believe I've
witnessed a compiler ever enforce that requirement.

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

There is nothing stopping you from resolving those conflicts in another
library/object file. However, you have a problem when a new revision of
the library comes out, it may be that the interface is changed such that
your code may need to be dramatically changed - not fun.

Can any one elaborate on this issue?

If anyone on my dev team were to do this, they would be severly chastized.

 

[Alf P. Steinbach]

* Chetan Raj:

One of my friend asked this question on C++

Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit
<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

Nope, we don't all know that: you can access the private variables all you
want.

Instead of editing the header files you can duplicate the declarations.

Or whatever, including pointer hacking.

Can any one elaborate on this issue?

It's very simple. 'private' is protection against _inadvertent_ access of
private things, and helps to avoid name collisions. It's not a security
measure. Anyone can access anything if they're really determined.
'private' is not protecting against hacking: it is a design tool.

 

[bala]

May be...

when u edit the interface, you just change it. The implementation is in
..a or .so files ( whatever). And you can't change it.

And i think, those .h'ss are read only and to be used when u write the
client code.

 

[ben]

Access control is a language mechanism for organizing large scale software
construction. The sole purpose of access control is to limit the number of
elements that can be affected from code change, i.e. if you decide to change
the implementation of a class, as long as you keep the public interface
unchanged, the only things affected by the change are the member functions
of that class and friend classes.

Yes you can change the header and get access to private member of library
code. But at what price? You don't get privilege doing that, and most
importantly, if you write 10000 lines of code that accesses to the private
member of a class, you'd hope that the class doesn't get updated because
otherwise you will have 10000 lines of code to review.

ben

[excess quoting deleted -- mod]

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

Can any one elaborate on this issue?

[excess quoting deleted --mod]

 

[Murali]

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

Without going into the merits of why you should do this, the answer
would be: Yes, you can edit the .h file and add a friend function
declaration
and access the private members of the class from that function. The
compiler will not complain.

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

Yes, but it is a very basic and important issue. Note that C++ access
specifiers are for data encapsulation and are not for preventing
intentional misuse.

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

If you change an existing class's definition in the header file in such
a way that it becomes incompatible with the one used by the library,
then you could be hit by any number of compilation errors and run-time
errors.
However, adding a friend declaration as mentioned above should not
cause the linker to complain.

Regards,
Murali

 

[James Daughtry]

Let's just say no and be done with it. If a class wants you to look at
its private parts, they will be protected and you can use inheritance.
Some standard libraries support non-standard functionality that allow
you to do just that. For the iostreams, you can extend them with
inheritance or without inheritance through streambufs, locales,
callbacks, and the xalloc/iword/pword mechanism.

 

[Allan W]

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

The standard doesn't say what will happen here. However, I've never
used a compiler where this wouldn't work (though I've heard of some
where some or all of the standard headers aren't literally text
files -- obviously it wouldn't work there).

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

Very destructive! Please don't do this unless you've found a bug in
the library that can be fixed just by editing header files. (Most
template code falls into this category.) Even then, please check for
official "patches" instead of fixing it yourself!

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

AFAIK, most compilers don't carry public/private information in object
code -- they rely on the One Definition Rule (ODR), and assume that
the header files have NOT been altered. Search the FAQ for "ODR".

Please don't literally edit the header files directly -- you'll find
it hard to get them "back to normal" when you come back to your senses.
(You might have to re-install the entire compiler.) Instead, use a
trick like this:

// Define SANITY when you have come to your senses
//#define SANITY
#if !defined(SANITY)
#define class struct
#define private public
#define protected public
#endif
#include <whatever>
// You now have access to all private members of ALL classes

Obviously UB (Undefined Behavior) is going to be different from one
compiler to the next. Theoretically this type of playing could affect
the way that data members are packed into a structure. But I think
that on many compilers this will do exactly what you probably expect!

So you can do this for toy programs. But, like any other UB, you
can assume that it's going to seem to "work" until it matters most --
probably the day after you've burned CD copies of your finished
programs and started shipping them to paying customers -- and then
it will do something nasty. Therefore you should avoid doing this
in production code!

 

[Hyman Rosen]

Can I edit the .h file to declare my own function as friend inside
the class declaration and then gain access to private data members
of ostream? Will the compiler allow this?

That's a quality of implementation issue. By having two different
definitions of a class in the same program, you are violating the
ODR (one-definition rule) and that causes undefined behavior.

 

[Francis Glassborow]

Hi All,

One of my friend asked this question on C++


Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

1) There are no .h files in the c++ Standard (other than those inherited
from C, which do not have any uses of private in them)

2) Any time a programmer alters or inserts anything to namespace std
they need to check that it is one of the very limited cases where that
is permitted.

3) private is not designed to prevent theft or invasion only to help
detect accident.

4) If you really want to steal access just try:

#define private public

Of course the consequences are entirely undefined.

 

[Michael Tiomkin]

Hi All,

One of my friend asked this question on C++


Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

I don't see a problem with this. Recall that the relative offset of
an attribute in an object is known in compile time, and the compiler
can easily create direct access to it.

Notice that you can also gain access to private attributes (data
members) using a debugger!-)

C++ gives you access control only if you follow the guidelines, this
is similar to the road where you can almost always ignore the rules and
drive your SUV in a different way.
If you want to better hide your data, you need to put it on a
different computer and control the traffic on it.

The problems with using private parts of the ostream:
1. Whenever its .h is changed, you'll need to change your "private" .h.
2. If you use private methods, these methods can be hidden in the .dll
- not exported to the outside world.
3. Safety - you can access private attributes when they are in an
inconsistent state, like accessing the file buffer when it's being
updated.

The most accepted way to hide your data is to have different
implementation and declaration files, define a ptr to an object as an
attribute, and avoid publishing it's declaration, e.g.

// declaration file
class C_helper;
class C {
C_helper *helper_attr; // the .h for C_helper is not here
// declare _helper and use helper_attr in the implementation file

I think you can find more detailed examples in almost any design
patterns book.

Michael

 

[kerzum]

Yes, this is possible. Friend declarations have no effect on class
layout and are only considered while
compiling friends.

We all know that this will not be possible, because the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

Library files hold no access control information, so public members are
stored exactly the same way
as private. Actually those names will be compiled to offsets, according
to class definition, no matter
public or private.

 

[Vorticity Kappa]

Hi All,

One of my friend asked this question on C++



Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

Can any one elaborate on this issue?

Restricted access (private & protected) variables provide a way to say
"This is an implementation detail, not part of any contract; if you
ingeniously make yourself dependant on it, you're on your own".

They are not secure. They've never been claimed to be secure.

This has nothing to do with whether unsanctioned access to privates in
some framework could constitute a security breach - but if such is the
case, it's a failure of the framework design, not of C++.

 

[thoth39]

The compiler obeys the instructions set in the source code. If you
change the source code, you change the instructions. As long as
everything is valid C++, the compiler will generate code.

Of course, even if you *can* modify the headers of your standard
library implementation to allow access to private data members, you
shouldn't; there's some discussion in the C++ FAQ Lite, around here:
http://www.parashift.com/c++-faq-lite/classes-and-objects.html#faq-7.6

Also, if you want to mess with *protected* data members of a class, you
don't need to modify is declaration in any way; just inherit from it.

 

[Chetan Raj]

Hi All,

We have two kinds of linkages : internal and external linkages. In
internal linkages, the scope of the function or variable is limited to
the current translational unit. ( current .cpp file which the complier
is currently compliling to object file ) These functions or variables
cannot be accessed in other translational units.

So, cannot the complier make all private variables and functions
default to internal linkage and limit it accessing from any other
translational unit?

Thanks,
Chetan

 

[Jerry Coffin]

Chetan Raj wrote:

[ ... ]

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

Officially, the standard headers don't necessarily even exist as files
per se, so there's no guarantee that you can do this, and if you do it,
no guarantee that it'll do what you expect.

Unofficially, yes yo can usually do this, and get roughly the results
you'd expect.

Access control in C++ is intended to protect against Murphy, not
Machiavelli.

 

[Seungbeom Kim]

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

Isn't it undefined behaviour? When you say #include <ostream>, the
Standard doesn't even mandate the existence of a real file named such. A
conforming compiler could have all the information built in, and there's
no distinction between the compiler and the standard library files from
the viewpoint of the Standard, so I think trying to modify any part of
the "implementation" yields undefined behaviour.

 

[Hyman Rosen]

The standard doesn't say what will happen here.

Yes it does. Unless you recompile all compilation
units which include this class definition then you
are violating the ODR (one-definition rule) and the
program has undefined behavior. The compiler is not
required to diagnose this, but a high-quality
implementation would, presumably by incorporating a
hash of the class definition text into the mangled
name of the class so that the proposed change would
cause link failure.

 

[Hyman Rosen]

Yes, you can edit the .h file and add a friend function declaration
and access the private members of the class from that function. The
compiler will not complain.

No, you cannot, because you are violating the one-definition rule.
Any program which contains both the old and new definitions has
undefined behavior.

A high-quality compiler implementation should diagnose this, most
likely by incorporating a hash of the class definition into the
typesafe linkage of the class members.

 

[Francis Glassborow]

May be...

when u edit the interface, you just change it. The implementation is in
.a or .so files ( whatever). And you can't change it.

And i think, those .h'ss are read only and to be used when u write the
client code.

Yes, but read only can usually be fixed as well. Writing software
requires a sense of responsibility. Hacking original source code is a
mugs game. If absolutely necessary, use a copy. However if you find it
necessary you should ask yourself why you are using such poor quality
3rd party code.