[Info-vax] VMS process communication

[John Reagan]

On Monday, March 13, 2023 at 3:08:34 PM UTC-4, Arne Vajhøj wrote:
> On 3/13/2023 2:53 PM, John Dallman wrote: 
> > In article <tunp6s$3sc9i$1... at dont-email.me>, craig... at nospam.mac.com 
> > (Craig A. Berry) wrote: 
> >> On 3/13/23 8:40 AM, John Dallman wrote: 
> >>> Have you got a link for that? 
> >> 
> >> As far as I know it's only available in the service portal for 
> >> people with a support contract. I assume it will become part of the 
> >> standard, publicly-available docs once that compiler is out of field 
> >> test. 
> > 
> > Makes sense, thanks. It makes porting C/C++ applications to VMS a good 
> > deal simpler.
> I believe it always have been the message that: 
> * Fortran, Pascal, Cobol, Basic and C will get all the DCL command 
> qualifiers, VMS specific language extensions and VMS specific CRTL 
> functions needed to compile old existing code 
> * C++ would be clang ported to VMS close to "as is" 
>
There has been a constant drumbeat from customers (including many here
on this forum) about our odd choice of long=32-bit; ptrdiff_t=32-bit; 
size_t=32-bit all while you can say /POINTER=64.  For C++/clang, we just
get what clang gives you for a 64-bit compiler.

We have yet to provide a similar setting for the C frontend as so far it hasn't been
necessary.

We have modified/enhanced some headers to replace "long" with "int" to make sure
that certain fields that are 32-bits are still 32-bits with both x86 C and x86 C++.  

My desire is to limit the # of clang OpenVMS-isms to those actually needed and to
skip the ones that have been just dragged forward from VAX for no real reason other
than just the fear of pissing off a customer.  I'm in the "if you need it, ask and we'll
talk about it" camp.