#124 UDF cannot be used with the function-id if an alias is given

[csiedentop]

Edit by Simon the former invalid ticket changed to "accepted", see ToDo below.
Original ticket title "UDF alias name of the function is not used for a physical file".

---

When using a literal as an alias for a FUNCTION-ID, the name 'EXTERNAL-FUNCTION-NAME' of the following example is not used for a physical file.

function-id. UDFSyntaxDemo as 'EXTERNAL-FUNCTION-NAME'.
environment division.
configuration section.
repository.
    function internalFunctionName as 'EXTERNAL-FUNCTION-NAME'
    .
    ...
    move function EXTERNAL-FUNCTION-NAME('hello') to result

Expected (as of MF Visual COBOL 2.2):

function-id. UDFSyntaxDemo as 'EXTERNAL-FUNCTION-NAME'.
environment division.
configuration section.
repository.
    function internalFunctionName as 'EXTERNAL-FUNCTION-NAME'
    .
    ...
    move function internalFunctionName('hello') to result

Micro Focus generates a file with the name 'EXTERNAL-FUNCTION-NAME.obj'.

System: GnuCobol 2.0, Windows 7, MS VC 32-Bit Version 16.00.30319.01
Compiled with: cobc -x UserDefinedFunctionDemo.cob UDFSyntaxDemo.cob.

A complete demo is attached.

Carsten

[Brian Tiffin]

Just as an FYI, I tried the sample on a Fedora 19 system, and it works.

Carsten; A little unclear, so I'll ask for more clarification, along with what I see from initial look.

As the sample worked here. First up, did you expect internalFunctionName to work, or the EXTERNAL-FUNCTION-NAME ?

Then some explanation from a GNU/Linux perspective.

cobc -m UDFSyntaxDemo.cob

will create a .so with EXTERNAL-FUNCTION-NAME accessible to the linker (plus or minus some name mangling for - and __

to be platform specific with Fedora,

EXTERNAL__FUNCTION__NAME

is what is used for the mangled name.

nm UDFSyntaxDemo.so
..
0000000000000d25 T EXTERNAL__FUNCTION__NAME
..

It would be relatively easy to generate a .o (.obj) file for a single function, cobc -c with judicious use of filenames, but I'm not sure what you are aiming for, Carsten. And from what I can tell from the source code, you know this stuff, so, blame my requests for clarification on my lack of trying it with Micro Focus, to see what to exepect.

changed COBOL tags to cobolfree for clearer highlighting on your ticket Carsten

Simon changed this post for the highlighter don't mess with the function name (it "recognized" the underscores as an order to write FUNCTION in bold) ;-)

[Simon Sobisch]

First to say: it's a good bug report with everything in to reproduce (although I did have to open the attachment to fully understand the issue.

I think Carsten expect the resulting file to be not named UDFSyntaxDemo.dll/so but something like EXTERNAL-FUNCTION-NAME.dll/so. Is this correct Carsten?

If yes: I'd close this ticket as invalid as it's not bug (the standard doesn't state how the physical COBOL files have to be named) but a difference in the compiler. Therefore "we" (pointing at Brian and/or Gary) should document this and can close the report.

In the end the main issue in the "bug" report is that both compilers are told to do different things in the attached sample.

MF:

• compile UDFSyntaxDemo.cob to an object file (with MF generating EXTERNAL-FUNCTION-NAME.obj; GC would generate UDFSyntaxDemo.obj)
• compile UserDefinedFunctionDemo.cob and the previously compiled object file into a combined UserDefinedFunctionDemo.exe

GC:

• compile UDFSyntaxDemo.cob to an dynamic link library (GC generating UDFSyntaxDemo.dll, MF would likely generate EXTERNAL-FUNCTION-NAME.dll)
• compile UserDefinedFunctionDemo.cob and (again) UDFSyntaxDemo.cob into a combined UserDefinedFunctionDemo.exe (which doesn't even try to load the previous generated dynamic link library

To do the same as with the MF compile.bat you'd do

cobc UDFSyntaxDemo.cob -c
cobc -x UserDefinedFunctionDemo.cob UDFSyntaxDemo.obj

or, if you need the external object renamed

cobc UDFSyntaxDemo.cob -c -o EXTERNAL-FUNCTION-NAME.obj
cobc -x UserDefinedFunctionDemo.cob EXTERNAL-FUNCTION-NAME.obj

If you want what you told cobc in your compile.bat (compiling the function to a loadable module file) it would be

cobc -m UDFSyntaxDemo.cob
cobc -x UserDefinedFunctionDemo.cob

and for running

set COB_PRE_LOAD=UDFSyntaxDemo
UserDefinedFunctionDemo.exe

Just for adding this to answer the more or less asked question what the standard says (and to show that both GC and MF are correct):

11.5 FUNCTION-ID paragraph
The FUNCTION-ID paragraph specifies the name by which a function is identified and assigns selected attributes to that function.

FUNCTION-ID. user-function-name-1 [ AS literal-1 ] .

User-function-name-1 names the function declared by this function definition. However, literal-1, if specified, is the name of the function that is externalized to the operating environment.

And it's externalized as both the running tests and the nm command (would be depends.exe in Windows) shows. With the special case that the hypens are replaced with two underscores at both compile (name generation) and run-time (function call).

I'm closing the bug report, it should be open for further discussions nonetheless (@Carsten: please answer and @Brian and/or Gary: please acknowledge to document the different generation of physical file names).

Simon

[csiedentop]

@Brian, @Simon

Right, it's not the correctness of the user-defined function (UDF)
at runtime. It's the name of the generated external file but ALSO the
usage of the name inside the procedure division. Compare:

When MF and GC declare the same:

program-id. UserDefinedFunctionDemo.
...
configuration section.
repository.
    function internalFunctionName as 'EXTERNAL-FUNCTION-NAME'.

then the invocation of the function in the procedure division is different:

MF:

   move function internalFunctionName('hello') to result

GC:

   move function EXTERNAL-FUNCTION-NAME('hello') to result

What does the standard say:

1.
The standard ('ISO/IEC JTC 1/SC 22') says "However,
literal-1, if specified, is the name of the function that is
externalized to the operating environment.".
So I think, the command

cobc -c UserDefinedFunctionDemo

should generate 'EXTERNAL-FUNCTION-NAME.obj' by default.
But you are right, it's not a big thing to use the -o option.

2.
The standard says nothing about the usage of the alias.
My recommendation is to allow both, the internal and the external name:

(1)   move function internalFunctionName('hello') to result
(2)   move function EXTERNAL-FUNCTION-NAME('hello') to result

Currently (GC 2.0) throws a compile error with the first statement.

When GC enables both statements, then GC is compatible to MF.
It's not my oppinion, that everyone should follow MF or IBM. But
GnuCobol can be the migration target for MF and IBM COBOL. And for that case
it would be one difference less, if GC enables both kinds of usage.

Carsten

[Simon Sobisch]

To 1) I only understand "externalize" the way GC currently does and this part would have no point if you group many functions into one source file (at least if you don't want to split the binary output in multiple files which doesn't sound useful to me.

2) finally leading to an accepted bug report :-) It should not break existing code (Who would use both the internal an the external in a conflicting way? He shall suffer from doing so ;-))

ToDo: Change parser to accept both the internal and the aliasname.

Simon

[Edward Hart]

Fixed in [r826].