support for compliance with CRAN repository policies

[drwolf85]

When using mimalloc as a subtree in the source code of an R package, the static library embedded in a shared object failed to pass CRAN checks for compiled packages. I fixed the library mainly using preprocessor directives. Issues with pragma statements disabling GCC warnings were solved using comments.

[drwolf85]

@microsoft-github-policy-service agree

[res2k]

While I'm not making the call whether to merge this or not, if I would, this would get a rejection.

Let me elaborate.

You're trying to solve a very specific issue ("CRAN complicance") in the upstream repo, which is used in a lot more scenarios, with occasional seemingly little regard how it may affect others. It's probably also a potential source for bit rot, as this particular scenario is rather special.

• You're removing some comments/#pragmas without replacement. While I don't know the reason for them either, I assume they're there for a reason, and shouldn't just be removed.
  Perhaps the conditions around those pragmas could be made tighter, or perhaps there could be a build option that specifies that some warnings are wanted.
• _mi_prim_out_stderr() is changed to a no-op. A much more generic approach would be some option that specifies that the user will provide a custom implementation of that function; of course, a no-op would be a possible custom implementation.
• Similar the "fall back to fputs".
• #include <R.h> has really no business here. (If everyone would pull headers from the project the integrate mimalloc in, where would it end?) The reason is that you want to use Rf_error. Again, a more generic approach would be some way to have the user provide a custom new failure handler.
• Similar for other uses of Rf_error.
• The inclusion (or not) of build date/time could perhaps also be a build option.
• The condition in _mi_fputs looks a bit weird to start - comparing a function pointer with stdout/stderr. Perhaps here it would be possible to provide some general cleanup, ie ensuring that it won't be called with a file handle as the output function... (Though there may be compatibility implications.)

So with generic solutions to your issues in place, you could specify appropriate build options & behavior customizations in the project(s) that embed mimalloc, instead of requiring some rather specific and peculiar upstream changes..