[Info-vax] DEC C 64/32 bit pointer conversion question

[Stephen Hoffman]

On 2019-09-16 23:18:49 +0000, John E. Malmberg said:

> On 9/13/2019 3:37 PM, Arne Vajhøj wrote:
>> Can you provide a two module example showing the problem?
> 
> I found out what I was doing wrong.
> 
> And I was looking at the wrong value in the debugger.  The value was 
> something like 80000020
> 
> A 32 bit pointer on VMS is actually only 31 bits, not 32 bits.

The brilliant-but-morass that is the 32-64-bit design of OpenVMS 
strikes anew.  The more I work with this design, the more I dislike it. 
 (Yes, I do understand that some of the libraries will never migrate. 
Those will need to be replaced or retired.)

Pointers on OpenVMS are 32 bits or 64 bits.

Process space pointers for P0/P1 have 31 non-zero bits at most, and P2 
pointers have at most 63 bits; the most significant bit is always clear.

System space pointers have 32 or 64 bits, and the most significant bit 
is always set.

I suspect you've a signed lurking in the mix here.  Switch everything 
to unsigned, and try again.

Promotions and demotions involving a mix of and signed transitions get 
hairy, and there are unsigned to signed transitions expected when 
promoting.

When truncating, you really don't want to get signed 
truncations/demotions into the mix.

Arguably, only bitmasks and ilk should be using unsigned, and 
everything else should be signed integer. (Yeah, I've heard arguments 
the other way, too.)

I'd also use uint32_t and uint64_t here—that's actually all supported 
on HPE OpenVMS—and avoid the long long and unsigned long long stuff for 
this case, and would look to use uintptr_t (if that's even implemented 
on OpenVMS, I haven't checked) where available and needed.  uintptr_t 
will give you an object that'll hold a void pointer.

It's technically undefined behavior, but a union will also work here.  
But you're likely already deep in undefined behavior with this whole 
pointer-truncation requirement.  And I'd likely use a union here, as 
it'll be a very clear indication of what you're doing.  It's unlikely 
that this or most any other C code will ever end up executing on a 
ones' complement environment, so there's that.

The not-twos-complement is finally going away with C++20 and signed 
integers, though that won't cure all of this. Hopefully C follows.

Yes, I'd be willing to entertain a replacement for system programming 
on OpenVMS using C—Rust or whatever—but that's not currently an option.



-- 
Pure Personal Opinion | HoffmanLabs LLC