Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Pointer conversion macro brainteaser
Message-ID: <56197@microsoft.UUCP>
Date: 31 Jul 90 17:42:37 GMT
References: <43645@cornell.UUCP> <56042@microsoft.UUCP> <43906@cornell.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: comp
Organization: Microsoft Corp., Redmond WA
Lines: 34

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.