Oppolzer - Informatik / Blog

Am 24.03.2014 04:09, schrieb P.F.:
> On 03/23/2014 06:28 PM, Bernd Oppolzer wrote:
>>
>> The glue functions have to do the transformation of the PL/1 compatible
>> interface to the original interface of the C library.
>
> I think all the argument twiddling could be done in the C program
> (caller or callee) assuming you're willing to accept changes to the C
> code.
>

Yes, the twiddling is done in C code,

but

No, the original code is not changed, instead there are glue functions above the
original functions which modify the interfaces of the original functions and
present PL/1 compatible interfaces to the PL/1 caller (written in C)

> ...
>>
>> With the problem of NUL-terminated strings, you have to make a decision;
>> either PL/1 or C has to accept the logic of the other side. If the PL/1 side
>> wants the strings to be filled with blanks and have no NULL termination;
>> C can cope with this (but you have to take care, if you want to use some
>> of ther str... functions, anyway). If you want the strings to have nulls, you
>> have some troubles on the PL/1 side ... with old compilers, the new
>> ones have CHAR (x) VARZ, which is one of the nicest things if you
>> have to deal with C functions from PL/1 callers.
>
> On the other hand this is (mostly) easily handled by PL/I.  A PL/I
> program passing a (nonassignable) string argument to a C function can
> just pass the argument as the expression ('string' || '00'x).

Yes, we did that occasionally in former times, when there was no CHAR ... VARZ

>
> [To digress a bit, Iron Spring PL/I has the procedure and entry option
> LINKAGE(SYSTEM) - borrowed from OS/2 PL/I - to generate C-compatible
> calls and entries.  I haven't yet implemented the new(ish) options
> like BYVALUE, etc., but I have found I can do everything I need using
> this.]
> ...

we also found our ways to do all necessary things with older PL/1 compilers, for
example: NODESCRIPTOR can be simulated by passing a scalar variable (DEC FIXED
(1) for example), which is based on top of the argument to be passed, which
would generate descriptors otherwise, for example a char string or a structure.

>>
>> Kind regards
>>
>> Bernd
>>
>> Am 23.03.2014 21:44, schrieb S.H.:
>>>
>>> One thing you can do to alleviate a bit of pain is to have parallel PL/I and C
>>> include files that declare such things as array dimensions and string lengths,
>>> to avoid the trap of parallel maintenance.  You could even do a script that
>>> would generate both from a common source, and make that a step in the build
>>> script.
>
> S. - here I'm not on as sure ground, but I used to generate
> dual-language PL/I and ASM  include files using logic stolen from
> IBM's PL/S and ASM macros.  I think you could do the same with PL/I
> and C.  For example having the PL/I left margin start at 4 you could
> code the PL/I definition first surrounded by '/*' in columns 2 and 3
> to make them comments for C.  At the end the PL/I code could %GOTO the
> end, the %GOTO followed by the C code.
>
> What we really need is SDL (like your script) to maintain a set of
> language-independent definitions and then generate both the C and PL/I
> declarations.  Oh well, someday.
>

At our site we have a repository where we store our structure
and interface definitions in a language independent format
and generate definitions from there, in ASSEMBLER, PL/1 and C,
which are guaranteed to match.

Kind regards

Bernd