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

[Stephen Hoffman]

On 2015-06-15 17:05:59 +0000, Hans Vlems said:

> Op maandag 15 juni 2015 13:27:11 UTC+2 schreef Simon Clubley:
>> [snip]
>> 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.

Descriptors and itemlists are unfortunately big piles of glue code and 
generally clumsy to deal with in C and assembler, whether as the 
emitter or as the consumer.

Itemlists are a similar problem and a similar pile of glue code in 
BASIC, Fortran, COBOL and similar.

> Quite right, there aren't that many languages out there with native 
> support for item_lists (BLISS probably being the only one).

Arguably also Macro32 with $GET_ILE_FIELDS and related, as well.   That 
you're working with something tailored for Bliss and assembler should 
be a clue that there's something slightly wrong or crufty or limiting.  
 That the two lowest-level languages are your primary choice, that 
their replacement language C doesn't do this at all well, and that 
there are more than a few reports of problems with folks using 
itemlists from languages such as BASIC, Fortran or COBOL here — other 
languages which have their own LIB$ variations of the itemlist-based 
calls.   SDL — the core data definition language for OpenVMS itself — 
didn't get support for descriptors until comparatively recently in its 
existence, too.   Then there's smg$create_menu.   And then there's 
64-bit itemlists and 64-bit descriptors.  Ayup there's definitely some 
code smell here.

> But it is not very difficult to set up a couple of supporting functions 
> in C that allow easy access to them. A lot easier than in Pascal I feel.

If you're willing to drop into to C or assembler, sure.   But then 
there's some added code smell here, too.

Apple and Microsoft both went OO approaches here, which is an approach 
which has its advantages and inevitably also some disadvantages.  
There's less glue code needed, and you don't have to have jackets.  But 
more than a few folks aren't ready for OO, or have huge piles of non-OO 
code that still needs to work.  So we're stuck.  The question then 
becomes what gets added to the older compilers, and whether VSI starts 
moving to an OO interface for applications; .NET or Cocoa or other such.

And VSI going its own way here with OO or language extensions still 
involves effort and probably not for all that much benefit, as 
programmers now have to differently-alter code when porting into or 
porting out of OpenVMS.   For a C application, what are the benefits 
past those of a modern C library and C APIs and common libraries, for 
instance?

Folks point to descriptors as a way to avoid buffer overruns and that's 
true, but you're still not dealing with garbage collection, and you're 
also not appreciably past what a C code migration to somewhat more 
modern and somewhat safer C calls (strnlen, strlcpy, strlcat, strcpy_s, 
strcat_s etc) can provide.  (See the C11 annex, or 
<http://sourceforge.net/projects/safeclib/> — yeah, I know, 
Sourceforge.  Sorry.)  But if you're going to do the work, moving to OO 
languages and interfaces will have all the capabilities of descriptors, 
and rather more.




-- 
Pure Personal Opinion | HoffmanLabs LLC