[Info-vax] Creating an open source version of VMS, was: Re: OpenVMS Hobbyist Notification

[Arne Vajhøj]

On 3/12/2020 4:10 PM, Arne Vajhøj wrote:
> On 3/12/2020 3:20 PM, Simon Clubley wrote:
>> On 2020-03-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>> On 3/11/2020 10:12 PM, Simon Clubley wrote:
>>>> A really good example is RMS and the control blocks and what happened
>>>> during the move to 64-bit processes.
>>>>
>>>> In Unix land, an address variable looks like this:
>>>>
>>>>     {some data type or struct} *ptr;
>>>>     ptr = data_structure->flink;
>>>>
>>>> The Unix land compiler, regardless of language, handles all the 
>>>> conversions
>>>> from 32-bit pointers to 64-bit pointers when you rebuild this code for
>>>> 64-bit mode without you having to change this code.
>>>>
>>>> In VMS land, thanks to the need to support Macro-32, an address
>>>> looks something like this:
>>>>
>>>>     uint32 ptr;
>>>>     ptr = (uint32) source_address;    /* YUCK YUCK YUCK ! :-) */
>>>>
>>>> with total loss of any address attribute information.
>>>
>>> ????
>>>
>>> When I search after $l_fab, $l_rab, $l_nam, $l_kbf, $l_rbf, $l_ubf
>>> etc. I see pointer and pointers.
>>>
>>> You don't?
>>
>> They may be called "pointers" but they are nothing like the abstracted
>> pointers you see in a modern environment, including in C and Unix.
>  >
>  > They are nothing more than raw longwords that have had an address
>  > forced into them.
> 
> ????
> 
> As far as I am aware C old or new only got one type of pointers,
> those you declare like:
> 
> type *var;
> 
> The C header files for RMS definition on VMS contains:
> 
> struct xxx {
>     ...
>     struct yyy *xxx$l_yyy;
>     ...
> }
> 
> How does your "the abstracted pointers you see in a modern environment"
> do that?

And where do you see:

 >>>>     uint32 ptr;
 >>>>     ptr = (uint32) source_address;    /* YUCK YUCK YUCK ! :-) */

?

Arne