peierls@svax.cs.cornell.edu (Tim Peierls) (07/23/90)
The overparenthesized and implementation dependent nightmare below
"converts" a base pointer to a derived pointer, in defiance of the rules.
If you don't see any use for such a trick or if you are appalled at
the whole idea, then read no further.
The question is, for all you spec hackers, under what conditions is
this macro guaranteed by E&S to work? By "conditions" I mean nasty
things like implementation defined behavior, and by "work" I mean conform
to the description below in some useful if not rigorous way.
#define bp2dp(B,D,p) ((p)?((D*)(((char*)(p))+1-((size_t)(B*)(D*)(void*)1))):0)
Usage:
B* bp;
D* dp;
dp = bp2dp(B,D,bp);
Assuming that class D is (non-virtually) derived from class B, the
macro takes a B* and returns a D*, such that (using the example names)
"bp == (B*) dp", for all bp for which "(B*) dp" is defined (including 0).
It works for cfront 2.0 and probably everywhere else. A reasonable
translator or compiler should have no problem turning the entire
expression into a compare and a subtract. For example, cfront turns
((B*)(D*)(void*)1) into a conditional expression with a constant
condition that cc can turn into a constant expression.
A related question: When does the offsetof(T,mem) macro work?
(It's defined in my stddef.h.)
Name : Tim Peierls
Mail : peierls@svax.cs.cornell.edu
Scotch : Laphroaigjimad@microsoft.UUCP (Jim ADCOCK) (07/25/90)
In article <43645@cornell.UUCP> peierls@cs.cornell.edu (Tim Peierls) writes: |The question is, for all you spec hackers, under what conditions is |this macro guaranteed by E&S to work? By "conditions" I mean nasty |things like implementation defined behavior, and by "work" I mean conform |to the description below in some useful if not rigorous way. | |#define bp2dp(B,D,p) ((p)?((D*)(((char*)(p))+1-((size_t)(B*)(D*)(void*)1))):0) If a coding trick uses any constructs considered by E&S to be "implementation dependent," then any "guarantees" from E&S are off. I don't have an E&S in front of me at the moment, but here's a short list of a few of the implementation dependencies I believe I see in this macro: * cast of small integer to void* * cast back of void* to something different than originally cast to void* * cast of B* to size_t * cast of B* to char* * use of odd address for structure pointer * cast of char* to D* |It works for cfront 2.0 and probably everywhere else. I disagree with both the first part and the second part of this statement. When I tried this macro on a cfront 2.0 derivative with B a virtual base class of D, the code compiled silently, then crashed at runtime. The reason it crashed was that in the case of a virtual base class, a D instance contains a pointer to the virtual base class B instance. Casting from D* to B* requires an actual evaluation of the pointer -- which resides in the hypothetical structure residing at address "1" Since the cfront implementation of virtual base classes seems reasonable [assuming one feels virtual base classes are reasonable :-] it follows that this macro will probably fail everywhere else too. |A reasonable translator or compiler should have no problem turning the entire |expression into a compare and a subtract. Again, not true if a class uses a virtual base.
peierls@svax.cs.cornell.edu (Tim Peierls) (07/31/90)
>In article <43645@cornell.UUCP> peierls@cs.cornell.edu (Tim Peierls) writes: >|The question is, for all you spec hackers, under what conditions is >|this macro guaranteed by E&S to work? ... >| >|#define bp2dp(B,D,p) ((p)?((D*)(((char*)(p))+1-((size_t)(B*)(D*)(void*)1))):0) >|It works for cfront 2.0 and probably everywhere else. > In article <56042@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >I disagree with both the first part and the second part of this statement. > >When I tried this macro on a cfront 2.0 derivative with B a virtual base >class of D ... > I did say in my original posting that D had to be derived non-virtually from B. I was looking for a characterization of implementations where this macro fails rather than an enumeration of implementation dependent behavior, but perhaps what you are saying is that no useful characterization exists beyond such an enumeration. I'll buy that. Name : Tim Peierls Mail : peierls@svax.cs.cornell.edu Scotch : Laphroaig
jimad@microsoft.UUCP (Jim ADCOCK) (08/01/90)
In article <43906@cornell.UUCP> peierls@svax.cs.cornell.edu (Tim Peierls) writes: >>In article <43645@cornell.UUCP> peierls@cs.cornell.edu (Tim Peierls) writes: >>|The question is, for all you spec hackers, under what conditions is >>|this macro guaranteed by E&S to work? ... >>| >>|#define bp2dp(B,D,p) ((p)?((D*)(((char*)(p))+1-((size_t)(B*)(D*)(void*)1))):0) >>|It works for cfront 2.0 and probably everywhere else. >> >I was looking for a characterization of implementations where this macro >fails rather than an enumeration of implementation dependent behavior, >but perhaps what you are saying is that no useful characterization exists >beyond such an enumeration. I'll buy that. Sorry, I forgot your restriction while I was trying to figure out what the macro was really trying to do. I take it the intent is to try to bypass restrictions on private derivation? What if an optimizing compiler uses the restrictions placed on private derivation as part of its optimizing scheme? Should optimizing compilers have to be pessimistic about their optimizations, assuming users will perform various pointer hacks? I might simplify your original question [slightly :-] as follows: When is pointer *arithmetic* *guaranteed* to work? Answer [I claim] : 1) When you're adding an integer offset to a foo ptr that points into an array of foos, or one off the far end, such that after the integer addition the foo ptr still points into the foo array, or one off the far end. 2) When you're finding the difference between two foo ptrs, both of which point into one array of foos, or one off the far end. 3) thats it, folks.