Am 04.12.23 um 22:46 schrieb Eric Sunshine:
> On Mon, Dec 4, 2023 at 9:19 AM Haritha via GitGitGadget
> <gitgitgadget@xxxxxxxxx> wrote:
>> diff --git a/fetch-negotiator.h b/fetch-negotiator.h
>> @@ -47,7 +47,7 @@ struct fetch_negotiator {
>> - void (*release)(struct fetch_negotiator *);
>> + void (*release_negotiator)(struct fetch_negotiator *);> diff --git a/fetch-pack.c b/fetch-pack.c
>> @@ -1232,7 +1232,7 @@ static struct ref *do_fetch_pack(struct fetch_pack_args *args,
>> if (negotiator)
>> - negotiator->release(negotiator);
>> + negotiator->release_negotiator(negotiator);
>> return ref;
>> }
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> @@ -223,7 +223,15 @@ struct strbuf;
>> +#ifdef __MVS__
>> + #define release stdlib_release
>> + #define fetch stdlib_fetch
>> +#endif
>> #include <stdlib.h>
>> +#ifdef __MVS__
>> + #undef fetch
>> + #undef release
>> +#endif
>
> So, the problem is that z/OS is polluting the C namespace or the
> preprocessor namespace with names "release" and "fetch"? When we've
> run across this problem on other platforms, we modify
> git-compat-util.h or some other files in compat/ to suppress the
> pollution introduced by the platform headers rather than "fixing" the
> Git source code. For instance, if "release" and "fetch" are macros on
> z/OS, then you may be able to simply #undef them after pulling in
> whichever z/OS header defines them. If they are actual system
> functions (rather than macros), you may be able to employ the
> #undef/#define dance to rename them to something else, such as
> "zos_release" and "zos_fetch" _before_ including the system header
> which declares those functions.
I assume that [1] and [2] link to the documentation of these functions.
Both pages include the following paragraph:
"To avoid infringing on the user's name space, this nonstandard
function has two names. One name is prefixed with two underscore
characters, and one name is not. The name without the prefix
underscore characters is exposed only when using the runtime library
extensions."
[3] defines "runtime library extensions" and mentions the macro __EXT
and LANGLVL(EXTENDED). Do you need those extensions? If you don't then
perhaps turning them off avoids the name collisions without needing to
change the code?
René
[1] https://www.ibm.com/docs/en/zos/3.1.0?topic=functions-fetch-get-load-module
[2] https://www.ibm.com/docs/en/zos/3.1.0?topic=functions-release-delete-load-module
[3] https://www.ibm.com/docs/en/zos/3.1.0?topic=reference-zos-cc-compiler-feature#compiler_feature__ext_lib_func
