[Info-vax] The Road to V9.0

[Simon Clubley]

On 2019-10-14, johnwallace4 at yahoo.co.uk <johnwallace4 at yahoo.co.uk> wrote:
> On Monday, 14 October 2019 13:50:40 UTC+1, Simon Clubley  wrote:
>> 
>> This memory pointer issue is one example of how the VMS data structures
>> and APIs simply tend to have a lower level of abstraction at source code
>> level.
>> 
>
> The (Open)VMS calling standard covers a lot of these 
> sharp edges, as do various flavours of descriptor, but 
> things like EDT and DIFF (and BLISS) do go back quite 
> a long time. 
>

That calling standard says it is ok to encode a pointer to a data
structure as a raw 32-bit integer instead of as some abstracted
language pointer which automatically changes size depending whether
you are compiling your code for use on a 32-bit or 64-bit machine.

When you are using something like fread() on Linux, you may or may not
have a 2GB/4GB/etc file size limitation but even when you do, you don't
have to read the buffer into the lower 32-bit address space until you
manually change your code.

>
> This isn't exclusively, or even primarily, an (Open)VMS 
> issue. E.g. just ask the many folks who were around when 
> the Sun community moved from 32bit to 64bit. Then there
> was DEC OSF/1 aka Tru64; compatibility with 32bit UNIX 
> code forced DEC OSF/1's 64bit compiler+linker to 
> introduce -taso ("truncated address space option")
> so that software that unwisely assumed that pointers 
> would fit in 32bits might stand a chance of working on
> Tr64. 
>

Yes, but they always had the language tools available to handle pointers
even if they didn't see the need to use those tools at the time.

When the need was pointed out, those people adapted to use the tools.
I've not seen any new application level C code in the last 20 years
or so that uses a 32-bit unsigned long int to store an address.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.