Based on the API, I think the intent (or at least the stylistically consistent behavior) is to have get_core_path return -1 to indicate failure, with the buffer contents unspecified in that case. The one caller of this function would operate correctly with that behavior.
Many of the platform-specific implementations of get_core_path appears to have error checking issues in varying degrees. (I looked at all of them and quickly spotted what look like bugs in most.)
Specific common categories of things I noticed
- Result of jio_snprintf is often not checked.
- Result of ::close() is often not checked. Consider EINTR.
- Result of ::read() is often not checked. Assumes no EINTR and no
partial read.
I suspect the last two are endemic in this code base. There are RESTARTABLE and RESTARTABLE_RETURN_INT macros to help with the EINTR case.
Many of the platform-specific implementations of get_core_path appears to have error checking issues in varying degrees. (I looked at all of them and quickly spotted what look like bugs in most.)
Specific common categories of things I noticed
- Result of jio_snprintf is often not checked.
- Result of ::close() is often not checked. Consider EINTR.
- Result of ::read() is often not checked. Assumes no EINTR and no
partial read.
I suspect the last two are endemic in this code base. There are RESTARTABLE and RESTARTABLE_RETURN_INT macros to help with the EINTR case.
- is blocked by
-
JDK-8073315 Enable gcc -Wtype-limits and fix upcoming issues.
-
- Resolved
-