[Info-vax] VAX VMS going forward

[David Jones]

On Friday, July 31, 2020 at 6:52:29 PM UTC-4, Craig A. Berry wrote:
> On 7/31/20 4:05 PM, David Jones wrote: 
> > If the header files have the proper prototypes, the compile will flag the calls 
> > with pointer mismatch warnings.
> So say you have a program with a 64-bit argv array and it invokes 
> various other programs via execv(). What happens when the main() 
> function of one of those programs expects a 32-bit argv array and it 
> gets your 64-bit array? 
> 
The programs in the spawned processes start over and will build an argv[]
based on the pointer size qualifier used to compile those programs. There's
no cloning of memory like Unix fork.

> Now maybe the whole command line is flattened into a single string, 
> reparsed by DCL, and passed to the invoked program. That would be 
> horrible, but it would avoid the problem of mismatched argv pointer sizes.

I think argv and envp are passed by mailbox to the spawned process.

In real life, like I said, the compiler will emit warnings when you compile a
program that passes an array of long pointers to execv(). If you plow ahead,
it's going to treat the high order longword of argv[0] as a 32 bit address for
argv[1]. It's most likely 0, so execv() will truncate the argument list at that
point. If it's not 0, you get an ACCVIO or random string (then followed by
treating caller's 64-bit argv[1] as 32-bit argv[2]/argv[3]). 

The 'fix' is you build your own copy of argv[] with only P0 memory for the
array and copies of the strings the argv point to.

For the SQLite port, the general library (~240K source lines) compiles cleanly
with 64 bit pointers. All the OpenVMS-related messiness with 32 versus 64
bit pointers is in the custom VFS module. The command line program does
have to deal with a couple issues, such as pclose() requiring a short pointer to
the FILE object.