JDK-8232187 : Add os::strncpy_s
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-10-12
  • Updated: 2023-11-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8214777 - Avoid some GCC 8.X strncpy() errors in HotSpot
Relates :  
JDK-8223186 - HotSpot compile warnings from GCC 9
Relates :  
JDK-8252051 - Make mlvmJvmtiUtils strncpy uses GCC 10.x friendly
Relates :  
JDK-8232084 - HotSpot build failed with GCC 9.2.1
Relates :  
JDK-8214976 - Warn about uses of functions replaced for portability
Relates :  
JDK-8231600 - Avoid GCC 8 strncpy error in jdk.jdwp.agent
Description
Uses of strncpy sometimes trigger gcc warning -Wstringop-truncation.  Some have been correct warnings, some have been false positives.  It may also be that some uses aren't being warned about but should be, because strncpy can be tricky to use properly. The places where the warnings occur has varied between gcc versions.

Rather than responding to a different set of complaints from different versions of gcc, we should consider adding os::strncpy_s, modelled on the corresponding C11 function, and replacing uses of strncpy with uses of that function. [Later: A possibly better choice is strscpy; see comments.]

gcc metabug for -Wstringop-truncation bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
Comments
Some discussions regarding the "_s" suffixed functions from C11 Annex K: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm https://github.com/KhronosGroup/OpenXR-Hpp/issues/11 - see comment by Ybaldrid (2019-09-26) https://sourceware.org/glibc/wiki/FAQ - see "Why no strlcpy" (or why glibc doesn't support the Annex K functions)
26-04-2022
Another problem to solve is that strncpy, and so these warnings, may appear in other places in the JDK besides HotSpot. Just having a helper function in HotSpot's os namespace doesn't help those other places in the JDK.
29-09-2020
Also note that strncpy_s is part of C11 Annex K, which is optional, so even if we were using C11, that Annex might not be provided by some compilers, so we'd need to always provide our own definition. And it turns out not everyone is happy with that suite of functions either. There is a proposal to just delete Annex K: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
29-09-2020
Other alternatives include strlcpy (available on some platforms) and strscpy (used in Linux kernel). strscpy seems like the nearest thing to what we're generally trying to do, assuming one actually checks the result. https://www.kernel.org/doc/htmldocs/kernel-api/API-strscpy.html https://lwn.net/Articles/659214/ Regarding checking the result, C++17 has [[nodiscard]], and some compilers have similar attributes.
28-08-2020
[~iklam] I proposed adding os::strncpy_s, not os::strncpy; that trailing "_s" is important. The C11 strncpy_s function is different, attempting to address some of the potential problems that arise from strncpy and that -Wstringop-truncate is attempting to detect. Of course, if all uses of strncpy are converted (and we poison strncpy to prevent uses from creeping back in: JDK-8214976) that renders -Wstringop-truncate moot.
18-10-2019
If we turn every strncpy() call to os::strncpy(), would that be the same as explicitly turning off -Wstringop-truncate globally? Or, are you proposing only changing problematic cases to os::strncpy()?
15-10-2019