On Fri, 13 Dec 2024 08:10:10 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>>> `perror` will print the given message accrording the previous `errno` info >>> to stderr, so this change will not change the original behaviour. >> >> What do you mean? The original behavior would not write anything to stderr >> under any circumstance. >> >> Now since the file name comes from a loaded library, I can't possibly >> imagine anything (short of a provoked situation where someone deliberatly >> removes the library after starting the JVM or something like that) that >> would cause realpath to fail. So this is basically just about keeping the >> compiler quiet. >> >> Had we *really* expected that this could happen, this would not have been an >> accepted solution. Then you'd had to raise an exception, perhaps, and see >> if/how the operation could be retried, what consequences a failure would >> have, etc. >> >> But as I said, in this particular instance, it might be okay. > >> Should I combine 3 similar >> issues([JDK-8346104](https://bugs.openjdk.org/browse/JDK-8346104)/[JDK-8346103](https://bugs.openjdk.org/browse/JDK-8346103)/[JDK-8346059](https://bugs.openjdk.org/browse/JDK-8346059)) >> to 1 issue > > I personally would probably have started out by making a single issue for > these, since they all try to address the same new warning in clang, and are > all in client code, and only split it up later if reviewers had requested it. > But since you have created separate issues, I suggest you do not change > things now. Also, the other two I believe need a more serious response; a > write to a pipe has a somewhat more realistic chance at failure than this > filename lookup. Sorry for the confuse. I mean this PR change nothing except it will print a message to stderr when realpath return NULL. Thanks magicus. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22701#discussion_r1883544101
