PLINK v1.9 sprintf() compilation warnings: Does a way to silence/fix them exist?

[VicBoss1984]

Hi everyone,

I am curious if someone on an M-series Apple Macintosh computer was able to build PLINK version 1.9 without getting the sprintf() deprecation warnings when compiling/building from source. PLINK version 2.0 does not have this issue but PLINK version 1.9 does.

I tried to compile PLINK version 1.9 by running make under the 'build_mac' subdirectory, but I am running into issues with missing 'zlib' for AMD (which I presume refers to the x86 version of 'zlib' on Mac). I can modify the makefile under the 'build_mac' subdirectory to point to the 'arm-64' version of 'zlib' that comes pre-installed with my Macintosh computer/system, but I am wondering if doing so is recommended. I can even remove the instances and references to the 'AMD' version of 'zlib' in the Makefile, but I am not sure if that would lead to unintended consequences when it comes to building the final 'PLINK' executable.

I tried compiling v1.07 of PLINK using the instructions provided in the official website, but I get a compilation error that halts the build process. There is apparently an issue with the redefintion of a variable in 'sets.c' that is halting the build, but I am not sure how to fix it without introducing new bugs/issues into my build of PLINK v1.07.

Many thanks,
Ali

[chrchang]

• Removal of the remaining PLINK 1.9 sprintf deprecation warnings was judged to be more likely to introduce than fix bugs.

• You are expected to run the plink_first_compile script to download/build zlib: https://www.cog-genomics.org/plink/1.9/dev#compile .

[VicBoss1984]

Hopefully and if I have the time, I will look into figuring out how to replace all invocations of the sprintf() function in the codebase without introducing new bugs. Since this issue can affect users on different platforms, it is worthwhile to investigate and fix.

I am going to see if using the snprintf() function instead of sprintf() can work without introducing new bugs/errors into the codebase. I will fork the 'plink' repository, create my own branch, develop the changes, and test them. If all goes well, I will report back and document the changes into a PR.

Thank you for responding to the issue so quickly and diligently. Now that I know this is not a platform-specific issue, it is now worthwhile to try and fix it so that everyone can benefit.

[chrchang]

Ok, good luck. Just be aware that the "easy" sprintf() -> snprintf() conversions were already made. The few sprintf calls that remain don't have buffer-size information immediately available, lower bounds on those values will need to be calculated and passed down from callers for snprintf to be used correctly.