Issue with strings.h and application that defines its own "mcpy" function.

[fswarbrick]

So I am porting JOE (Joe's Own Editor) and running in to an annoyance. JOE defines a function named mcpy. When a file that includes strings.h and has its own mcpy() declaration is compiled it gets an error that there are conflicting types for 'mcpy'. This is because strings.h contains a declaration for a function called mcpy.

If the file that includes strings.h is compiled with no special macros defined at compile time this error does not occur. However, it looks like ZOT includes both -D_XOPEN_SOURCE=600 and -D_ALL_SOURCE, which in turn sets the __UU macro. If the __UU macro is defined then the declaration of mcpy is done when strings.h is included.

The first question I have is what is the point of strings.h declaring mcpy. It does not appear to be a member in the z/OS runtime libraries. I wonder if it is a legacy declaration in strings.h that is no longer required. I realize this would be a z/OS base issue, not a ZOT issue.

In any case, any thoughts on the best way to get around this? The way I've done it at this point is to copy /usr/include/strings.h in to the application's source directory, and then remove the declaration. With this and a few other minor changes I have gotten JOE to function.

If you want to try it yourself, here is a tiny test program that demonstrates the issue.

#include <stddef.h>
#include <strings.h>

void *mcpy(void *a, const void *b, ptrdiff_t len);

int main() {
        char s[] = "test";
        char s2[80];

        mcpy(s2, s, sizeof(s));
}

And compile with
clang -D_XOPEN_SOURCE=600 -D_ALL_SOURCE memcp.c (obviously replacing clang with whatever C compiler you are using)

You will get results looking something like this:

memcp.c:4:7: error: conflicting types for 'mcpy'
void *mcpy(void *a, const void *b, ptrdiff_t len);
      ^
/usr/include/strings.h:203:17: note: previous declaration is here
         void * mcpy (void *, const void *, size_t);
                ^
1 error generated.

Without specifying the two macro definitions it compiles fine (but the link-edit fails because mcpy does not exist).

[IgorTodorovskiIBM]

Interesting, it's guarded out for xlclang, but not clang:

202        #elif !defined(__ibmxl__)
203          void * mcpy (void *, const void *, size_t);

FYI @perry-ca

One solution is to use a trick like this: https://github.com/ibmruntimes/zoslib/blob/zopen2/include/stdio.h#L33-L36

[fswarbrick]

@IgorTodorovskiIBM Yes, I'd like that.

[IgorTodorovskiIBM]

Great! https://github.com/ZOSOpenTools/joeport - you should have an invitation for access

[IgorTodorovskiIBM]

Are you on the System Z enthusiasts discord channel?

[fswarbrick]

I am not on that discord.

[IgorTodorovskiIBM]

If you're interested in joining, here's the invite: https://discord.gg/FhjY4tNH .