[Info-vax] VSI: "Official 8.4-1H1 Launch"

[Simon Clubley]

On 2015-06-10, johnwallace4 at yahoo.co.uk <johnwallace4 at yahoo.co.uk> wrote:
>
> You can indeed write code in multiple traditional languages on
> OSes other than VMS.
>
> On VMS it is trivial to do and because of the underlying
> language-independent standards such as the Calling Standard it
> is trivial to make multiple sensible languages interoperate
> reasonably well, so e.g. if you have a bit of FORTRAN that
> needs to call some pre-existing code in C (or whatever), there
> won't be too many issues. The documented standard also means
> that 3rd parties can, if they wish, develop conforming compilers
> and tools.
>
> Not sure it's quite so easy elsewhere. Possible, maybe.
>

The tendency in a number of areas appears to be to restrict yourself
to C language level cross calling compatibility.

> Even Microsoft eventually caught on to the value of a
> language-independent Common Language Runtime (which admittedly
> goes a bit further, in some ways, than the VMS Calling Standard). 
>
> And VMS has descriptors, architected in to the OS and many
> languages and associated runtimes, and in many languages they
> "just work", invisible to the user.
>

VMS descriptors are a really good idea I agree, but unfortunately
they are operating system specific and (as you point out) one of
the most common languages in use, C, has no builtin support for
them.

> Just think how many buffer overflow bugs would never have had
> a chance to exist if the descriptor concept had been widely
> used elsewhere. 
>
> Basic string handling? Don't hand code it, don't call K+R
> routines (sorry sirs), call the tried tested and proven STR$
> routines. And so on. A 17byte string into a 16byte space
> returning an error status, rather than scribbling on data
> it shouldn't touch, and **almost without the programmer
> having to think about it**, what a concept. Amazing.
>

The problem is that is VMS specific so no-one is going to use it
in any code which is going to be portable. What would be a _really_
good idea instead (and I _really_ wish they would do this) would
be for the C language committee to architect an additional descriptor
based or safe string handling library as part of the C language standard.

As such a thing would be a library written in standard C, there would
be absolutely no reason why implementations of this library couldn't
be added to existing C code bases created before this new library was
ratified.

As this would be an internally coherent library with support for
converting to and from existing null terminated strings when required,
the lack of builtin descriptor support in C should be far less of a
visible problem.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world