[Info-vax] c 7.3 - Why MAYLOSEDATA3 for long pointer math?

[John Reagan]

On Friday, March 13, 2015 at 7:55:37 AM UTC-4, Bob Gezelter wrote:
> On Thursday, July 24, 2014 at 9:01:00 PM UTC-4, John Reagan wrote:
> > On Thursday, July 24, 2014 6:41:41 PM UTC-4, Craig A. Berry wrote:
> > 
> > > Where there's a will there's a way. The Microsoft C/C++ compiler is a
> > > 32-bit program even when running on 64-bit Windows, but its size_t is 64
> > > bit when the build target is a 64-bit platform.
> > 
> > Didn't say it wasn't possible.  Just said it wasn't easy or worth our effort at the time.
> 
> John,
> 
> I know the queue of issues to be addressed is a long. Considering the impact on code porting of extant non-OpenVMS codebases, perhaps this decision should be reconsidered in the present context.
> 
> - Bob Gezelter, http://www.rlgsc.com

What decision?  The compiler behavior has not changed.  The 64-bit wide pointer subtraction is squeezed through the ptrdiff_t funnel like the standard says.  Only a warning was added to let you know that the pointer subtraction may not do what you intended.

The confusing issue to me (I wasn't involved on the C team when they added /POINTER_SIZE) is that /POINTER_SIZE=64 isn't really an LP64 setting.  'long' is still 32-bits, ptrdiff_t is still 32-bits, size_t (which has an indirect relationship with ptrdiff_t) is still 32-bits.  Some of that might have been due to the GEM interface for 64-bit size_t and some of that might have been due to the effort for the headers and RTL.

For code coming from the Linux world that is compiled with -m64 and assumes that long and pointers are the same size, we would need yet another setting (and all the matching header changes, etc).  I certainly would support such a setting (and have said so in the past).  It is on the list.  It isn't trivial.