scs@itivax.iti.org (Steve C. Simmons) (06/27/89)
solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes: >The trouble is that a class definition serves two purposes: to document >the class interface to a human user and to provide a compiler with enough >information to compile a client of the class. The private members are >superfluous (indeed, it could be argued they are harmful) for the former >purpose, but essential for the latter . . . Solomon goes on to detail his arguement, see the original if you like. If you really wanted to, it would not be particularly difficult to completely hide the private interface under UNIX. Put the public parts in as you would normally, but place private in a separate file/dir, eg, #include "/usr/include/c++private/your_class_here" Now make a new group, make the /usr/include/c++private directory and contents of that group, and make the appropriate c++ utilities sgid that group. Permit /usr/include/c++private 750, and you have a hidden area the compiler can see but users cannot. On the other hand, I would argue there is little to gain by hiding such from the programmer. By reading the private parts of the declaration one can get a better understanding of what the class really does. It helps nail down subtle performance things that might not be in the (probably non-existant) class documentation. Since the compiler does a pretty good job of enforcing privacy, the risks are very minor. -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
sdm@brunix (Scott Meyers) (06/28/89)
Actually, it would have been very easy to design C++ in such a way that the private data of a class didn't need to be specified in the class definition: represent each class object as a pointer to the real object. The price you pay, of course, is an extra indirect reference each time you refer to an object. There are other problems as well. This very point is discussed in THE C++ PROGRAMMING LANGUAGE at the end of section 5.3.1, page 145. I was amused to read Stroustrup's discussion of this issue, because a year or so ago this was the question I posed on the programming languages portion of the Ph.D. comprehensive exam here at Brown University. It's an interesting problem, because it reveals how programming language design is influenced by language implementation. Scott
camarena@Apple.COM (Herman J. Camarena) (06/28/89)
In article <1827@itivax.iti.org> scs@itivax.iti.org (Steve C. Simmons) writes: >If you really wanted to, it would not be particularly difficult to >completely hide the private interface under UNIX. Put the public >parts in as you would normally, but place private in a separate file/dir, >eg, > #include "/usr/include/c++private/your_class_here" >Now make a new group, make the /usr/include/c++private directory and >contents of that group, and make the appropriate c++ utilities sgid >that group. Permit /usr/include/c++private 750, and you have a hidden >area the compiler can see but users cannot. I think this approach does not work very well if you are developing the class. It could work if all your classes are "stable" at that point, of course the compiler should check the two copies to be sure they are consistant. ***************************************************************************** *Herman J. Camarena EMail: camarena@apple.com * *Network Systems Eng. {sun,decwrl,amdahl}apple!camarena * * USA Mail: 10500 No. De Anza Blvd. MS 27-O * * Cupertino, California 95014 * * AppleLink: CAMARENA1 * * Voice: (408)974-5164 * ***************************************************************************** * What you have just read are my opinions. They do not have anything to do * * with Apple's, even if they are good. * *****************************************************************************
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (06/28/89)
You *really* don't want to make any part of the compiler setgid. Writing secure privileged programs is *hard*; you have to think about what you're doing in advance. I'd lay heavy odds that it wouldn't be hard to trick a compiler into violating your security model; compilers are just too big, and too complex, to be ``trusted'' in that sense. As someone here has said, ``you don't give privileges to a whale''. Of course, the simple model given doesn't work anyway; what's to prevent me from using the appropriate options to just collect the cpp output? Ah -- make cc or CC setgid, then they can decide to reset the gid if the options appear to be secure, since they have to understand them all anyway. Then, of course, each component of the compilation system has to toggle setgid on and off when creating output files, to avoid a breach that way. Then -- but you get the picture. Returning to the original question, for most purposes I don't think it matters that the programmer can see the private sections of class definitions. I admit that my original reaction was the same -- but then again, I'm primarily a network security person, and ``cheating'' in this fashion seemed to be an information leak. But cfront isn't part of a trusted security kernel, and shouldn't be. The goal of private class components is to provide insulation, not total isolation. --Steve Bellovin
shankar@hpclscu.HP.COM (Shankar Unni) (06/30/89)
> Actually, it would have been very easy to design C++ in such a way that the > private data of a class didn't need to be specified in the class > definition: represent each class object as a pointer to the real object. $DRIFT ON$ Actually, there are two aspects to hiding information: the first could be simply to prevent the programmer from looking at the class internals. Another is to be able to minimize recompilation every time the implementation of some reusable class is changed. After all, the interface has not changed, so there is no reasonable reason for the callees to "change". It is certainly possible to implement such a scheme for the current definition of the language using pointers as described above. The compilers would completely ignore (for storage allocation purposes) the private parts, and the constructors would be responsible (this could be done automatically by the compiler) for allocating space for the private parts and virtual tables and all that cruft. In a rapid-prototyping environment, might even be a very desirable thing (if I change the internals of a class in a small way, I only want to relink my applications, not recompile all of them each time). The cost for this is a slowdown of the executable, but in such environments, this would be acceptable. After all, it is always possible to have a "production run" of the compiler to produce "efficient" code. $DRIFT OFF$ --- Shankar Unni E-mail: shankar@hpda.hp.com Hewlett-Packard California Language Lab ...!hplabs!hpda!shankar