Don't export system related symbols like strlcat

[schwehr]

I'm on a system where strlcat is not defined. netcdf then builds with strlcat and exports the symbol. Then a user creates a binary that links against another library that also doesn't see strlcat and also exports strlcat. The linker is then sad. Neither package should be exporting strlcat. I'm hacking around in my system by renaming strlcat to nc_strlcat.

Environment Information

netcdf 4.6.1 point release

Feel free to skip this if the issue is related to documentation, a feature request, or general discussion.

• What platform are you using? (please provide specific distribution/version in summary)
  • [x ] Linux = Custom
• 32 and/or 64 bit?
  • [x ] 64-bit
• What build system are you using?
  • bazel
• Can you provide a sample netCDF file or C code to recreate the issue?
  • No

Steps to reproduce the behavior

Link against something like unix file or https://virustotal.github.io/yara/

[DennisHeimbigner]

Good point. We can fix for netcdf-c by using a name such as "nc_strlcat" and
a macro #define strlcat nc_strlcat

[edwardhartnett]

I believe this has been fixed and this issue can be closed.

[schwehr]

Can you link to the commit where it was fixed?

[edwardhartnett]

No! ;-) But I seem to recall that Dennis fixed all these at one point. Can you look in the current main branch and see?

[DennisHeimbigner]

I was just looking at this. The change I made was to try and replace
use of strncpy with strlcat.

The code for the last resort strlcat is in netcdf-c/libdispatch/dstrings.c
So we could rename it to, say, nc_strlcat, and then modify the strlcat
related ifdefs in include/ncconfigure.h.

But is this problem restricted to strlcat? are there other functions in dstrings.c
that need similar treatment.