JDK-8220072 : GCC 8.3 reports errors in java.base
  • Type: Bug
  • Component: core-libs
  • Affected Version: 8,11,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-04
  • Updated: 2024-10-14
  • Resolved: 2019-05-22
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.
JDK 11 JDK 13 Other
11.0.20-oracleFixed 13 b22Fixed openjdk8u232Fixed
Related Reports
Relates :  
JDK-8220070 - Clean up GCC 8.3 errors
Description
GCC 8.3 output:

src/java.base/unix/native/libjava/canonicalize_md.c:214:9: error: 'strncpy' specified bound 4097 equals destination size [-Werror=stringop-truncation] 
         strncpy(path, original, sizeof(path)); 
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comments
Fix Request I would like this fix to be backported to 8u and 11u, to increase buildability with newer toolchains. I have confirmed that the patch merges into 11u without changes, and into 8u with the usual path changes.
19-08-2019
URL: http://hg.openjdk.java.net/jdk/jdk/rev/65b0b63d7f14 User: dchuyko Date: 2019-05-22 18:37:54 +0000
22-05-2019
http://cr.openjdk.java.net/~dchuyko/8220072/webrev.01/
21-05-2019
Yes, webrev.00 patch was incorrect so it was not sent to review, it also didn't pass testing.
13-05-2019
Ah, I see. We can add `path[PATH_MAX] = '\0';` just before strncpy(). Older comment should not be removed. (I saw webrev.00 from history)
09-05-2019
It's linked to in the comment before mine. Your suggested fix is also incorrect if strlen(original) == PATH_MAX, in which case the last byte of the path buffer will not be initialized and the string not correctly NUL terminated. Changing strncpy to copy PATH_MAX + 1 bytes should do the trick though.
09-05-2019
Where is the webrev.00??? BTW I think we can fix this issue as below: diff -r a8535f04b465 src/java.base/unix/native/libjava/canonicalize_md.c --- a/src/java.base/unix/native/libjava/canonicalize_md.c Tue May 07 18:24:36 2019 -0400 +++ b/src/java.base/unix/native/libjava/canonicalize_md.c Thu May 09 10:16:22 2019 +0900 @@ -211,11 +211,11 @@ char *p, *end, *r = NULL; char path[PATH_MAX + 1]; - strncpy(path, original, sizeof(path)); - if (path[PATH_MAX] != '\0') { + if (strlen(original) > PATH_MAX) { errno = ENAMETOOLONG; return -1; } + strncpy(path, original, PATH_MAX); end = path + strlen(path); for (p = end; p > path;) {
09-05-2019
FWIW the proposed change (webrev.00) is not correct since it leaves the last byte in the path buffer uninitialized and the check on the next line checks that uninitialized value.
09-05-2019