[Info-vax] Any Way to Pass Character String Arguments from C to Basic?

[Stephen Hoffman]

On 2019-10-21 19:19:40 +0000, Craig Dedo said:

> As you asked, here are the three descriptor definitions.
> 
> struct dsc$descriptor_d Customer_Location_Code_ldsc = { sizeof 
> (Customer_Location_Code_lsz) - 1, DSC$K_DTYPE_T, DSC$K_CLASS_D,  
> Customer_Location_Code_lsz };
> 
> struct dsc$descriptor_d Oldest_Invoice_Number_ldsc = { sizeof 
> (Oldest_Invoice_Number_lsz) - 1, DSC$K_DTYPE_T, DSC$K_CLASS_D, 
> Oldest_Invoice_Number_lsz };
> 
> struct dsc$descriptor_d Part_Number_ldsc = { sizeof (Part_Number_lsz) - 
> 1, DSC$K_DTYPE_T, DSC$K_CLASS_D, Part_Number_lsz };

That user C code is broken.  Badly.

You're also tunneled in on the BASIC code tipping over, and that's due 
to it being passed garbage input.

RTL calls that can allocate a dynamic descriptor include lib$sget1_dd, 
lib$scopy_r_dx, lib$scopy_r_dx_64, lib$analyze_sdesc, and others.  See 
also lib$sfree1_dd, too.

A developer is not permitted to initialize a dynamic descriptor with a 
non-zero length and with any associated storage.  Only with a 
zero-length and a zero buffer pointer, when creating a dynamic 
descriptor in C, C++, Macro32, etc.

struct dsc$descriptor_d Oldest_Invoice_Number_ldsc = { 0, 
DSC$K_DTYPE_T, DSC$K_CLASS_D, NULL };

Then lib$scopy_r_dx the data into the descriptor or such, and the RTL 
call will allocate the storage.

>From then on, it's only RTL calls that can allocate or deallocate 
storage or otherwise change the length of the dynamic descriptor.

And C, C++, or Macro32 code can need to deallocate a dynamic string, if 
there's associated storage.  That's via lib$sfree1_dd or analogous.  
Otherwise the code can or will leak storage.

Yes, allocating stack or user-controlled storage is permitted with and 
is required with static descriptors.  But dynamic descriptors are 
allocated from the heap, and the associated storage is entirely managed 
by the RTL.

You've effectively corrupted the heap with this pattern, when 
subsequent RTL calls try to free or try to re-size the storage.

Which is why the called BASIC code is crashing.

Whether the calling code can contend with a static descriptor as 
input—as differentiated from a dynamic descriptor—will depend on 
whether the calling code tries to re-size the descriptor.  Given that 
the called BASIC code is crashing, the called BASIC code is likely 
modifying the descriptor.  Maybe for a return?  And that's where the 
called code is failing.  As it should fail really, as it was passed an 
invalid dynamic descriptor.

C on OpenVMS is a mess here, and is still poorly documented and this 
having just checked the 
https://vmssoftware.com/docs/VSI_OpenVMS_BaseOS/5492_c_users_gd.pdf C 
User's Guide.  (Effectively no mentions of using dynamic descriptors, 
and little or none of 64-bit addressing and 64-bit descriptors, etc.  
You're assumed to know the calling standard here, unfortunately.  All 
discussions of C compiler extension gaps and C library descriptor gaps 
aside, calling into BASIC and Fortran and ilk from C or C++ can mean 
absurd heaps of glue code.

Unfortunately for any potential future remediation efforts that might 
arise here, OpenVMS-style descriptors are dated and limited.  Efforts 
toward hauling C and C++ and the existing OpenVMS APIs forward are an 
increasingly-larger project, and one that may well involve far more 
work and updates well past descriptors should VSI decide to haul this 
whole area forward. There are other APIU design approaches which are 
more flexible and more capable and much better for upward 
compatibility, such as the CLR 
https://docs.microsoft.com/en-us/dotnet/standard/clr and as the CLR 
looks a great deal like the OpenVMS calling standard evolved forward a 
decade or three.  There are other examples from other vendors.

You might also want to mention which calls are involved in the BASIC 
code, as those may well also be available from C.  That'll eliminate 
the BASIC code and the descriptors.



-- 
Pure Personal Opinion | HoffmanLabs LLC