[Info-vax] Any Way to Pass Arrays of Strings from C to Basic?

[Stephen Hoffman]

On 2019-11-09 16:47:50 +0000, John Reagan said:

> On Friday, November 8, 2019 at 2:10:56 PM UTC-5, Dave Froble wrote:
> 
>> 
>> Now, most of the VMS languages play rather well in such an environment. 
>> Then there is C, which does not play well in that environment.  There 
>> is the VMS calling standard, and, there is the VMS data types.  Use 
>> them, and things can work well.  C is not a native VMS language, as far 
>> as I know, and doesn't embrace the calling standard, nor the data types.
>> 
> 
> Huh?!?!?  Of course it does.

Ayup.  C absolutely uses the OpenVMS calling standard, or we wouldn't 
be able to call BASIC from C.

C certainly lacks argument-passing assists integrated into other 
OpenVMS languages here.  Same with Macro32 assembler.  C effectively 
being used as a higher-level assembler, that similarity and that 
omission is far from unexpected. With C and Macro32, you get to see 
more (most?) of what's going on when passing arguments around, and to 
variously write a fair chunk of it.

This mess has been one of my long-standing gripes with C on OpenVMS, 
too.  Too much glue code.  This after having seen changes to APIs 
else-platform which increasingly banish that glue code.

But there's little reason to implement (only) isolated API-related 
changes now within C.  If there's any work going into this area, it'd 
preferably be to drag the whole of the OpenVMS API and calling standard 
environment forward into this millennium; adopting support akin to the 
newer calling standards that are now commonplace on other platforms.  
End-user-and-ISV-developer-visible descriptor data structures and the 
closely-related itemlist data structures for API calls are just not 
centrally where the development world is headed, either.

> Descriptors are a mess.

Descriptors and itemlists are an utter disaster as a developer interface.

Descriptors and itemlists were and are great ideas from the waning 
years of the last millennium, allowing greater flexibility around what 
data can be passed, but expectations and abstractions and designs here 
have moved on in the ensuing ~decades.

Objects are just far easier, with far less user-written (glue) code, 
and far more capable, far more flexible, and are just as 
upward-compatible and variously more so.

> Try to handle a CLASS_VS descriptor when passed from Pascal to Fortran? 
>  Try to handle a 64-bit descriptor in COBOL or Pascal?

Ayup.  BASIC can't call a bunch of these APIs without hand-rolling descriptors.
Or try using 64-bit descriptor support in BASIC, for that matter.

> We used to have a real manual that listed all the descriptor kinds that 
> each language accepts for incoming arguments and which ones it can 
> produce for outgoing arguments.  The caller has the responsibility to 
> pass what the target wants (if you can figure it out).

And with a whole huge pile of glue code not related to the application 
itself, but solely around just using a platform-specific API.

Calling into non-portable and platform-specific APIs is one thing.

Requiring piles of platform-specific code to just use an API is vastly 
worse, as it adds bugs while drowning out the intent of the developer 
of the source code.

Applications managing descriptors needs to be related to legacy API 
status, but getting there is a whole lot of work.

But make no mistake, what's missing here in OpenVMS involves 
investments of a scale that hasn't gone into OpenVMS programming 
concepts and development tools and practices in a quarter-century, too. 
 And across at least several of the common programming languages, at 
least incrementally.  Work that includes tagging different languages 
and different character encodings (UTF-8, etc) and different sorting 
sequences, and a whole plethora of topics and details that are either 
ignored, or are more difficult to deal with, or that are home-rolled by 
OpenVMS developers.

BASIC has limitations around string handling and locales and sorting 
too, where at least C has limited locale support.  IIRC, the OpenVMS 
NCS APIs were deprecated by DEC.  DEC wasn't good at documenting what 
was deprecated, either.  What VSI now considers and what will be 
considered deprecated, and what the migration paths might be, we shall 
learn.

The lack of this investment is part of what makes the password hash 
such an intractable mess to upgrade.  And the password hash is not the 
only place in OpenVMS where the existing descriptor- and itemlist-based 
APIs have reached their limits.

Are objects a panacea?  No. But I'd much rather use objects in all but 
the most absolutely performance-sensitive code, or similar cases.  But 
I'd rather not be creating and parsing descriptors and itemlists in 
that same code, either.





-- 
Pure Personal Opinion | HoffmanLabs LLC