[Info-vax] VAX VMS going forward

[John Reagan]

On Friday, July 31, 2020 at 8:16:52 AM UTC-4, Craig A. Berry wrote:
> On 7/29/20 8:08 PM, Arne Vajhøj wrote:
> > On 7/29/2020 4:13 PM, John Dallman wrote:
> >> Can one build a program where pointers to data are /always/ 64-bit? Since
> >> I'd be porting code that is expecting uniform memory addressing, rather
> >> than dealing with different realms of data, that would make life much
> >> simpler.
> > 
> > $ CC/POINTER=64 ...
> > 
> > should go a long way.
> > 
> >> However, that gives me the problem that I can only call functions that
> >> take 64-bit pointers. Is the standard C library all set up for that? How
> >> about the threading functions? Those categories are all I need.
> > 
> > C User Guide section 1.7.3 has a little about it.
> > 
> > Also see John Reagan's reply.
> > 
> > In general I believe that if you have correct portable C
> > code then you will be in a pretty good shape with VMS
> > and 64 bit pointers.
> 
> Actually, it's only code written for VMS using native 64-bit interfaces
> that is likely to work with 64-bit pointers.  Portable code would have
> to live without the following from table 1-8 of the CRTL manual:
> 
> atexit         frexp           ioctl           setbuf
> execv          getopt          modf            setstate
> execve         iconv           putenv          setvbuf
> execvp         initstate
> 
> The problem is not the length of the list but what's on it.  It's hard
> to imagine a full-featured, portable program that does not use getopt,
> the exec family of functions, and ioctl.
> 
> In the case of the OP, a math library might be ok, but the user of that
> library who wants to write a program would have some hoops to jump through.

I agree.  Some of those 32-bit only ones need 64-bit solutions.  Not impossible for us to make a getopt_64 and then in the headers define a macro for getopt based on the command line.  We're doing some additional work right now on the RTL and I'll see about what we can do for some of these.