Comment by jstanley
13 hours ago
That's a pretty unfair characterisation of the commit in question: https://github.com/loongson/jdk/pull/125/commits/ee300a6ce73...
By my reading, it's not merely that the standard doesn't require the "d" suffix, it's that the standard doesn't allow the "d" suffix, and the code won't compile on anything but gcc.
Agreed, although things I immediately think of are:
1. Is "anything but gcc" actually supported by the project? Do they have a goal of supporting other compilers or possibly an explicit decision not to support other compilers?
2. If they do support other compilers, how did the "d" suffix make it in the first place? That's something I would expect the dev or CI to catch pretty quickly.
3. Does gcc behave any differently with the "d" suffix not there? (I would think a core dev would know that off the top of their head, so it's possible they looked at it and decided it wasn't worth it. One would hope they'd comment on the PR though if they did that). If it does, this could introduce a really hard-to-track-down bug.
I'm not defending Oracle here (in fact I hate Oracle and think they are a scourge on humanity) but trying to approach this with an objective look.
Given they have one to fix usage of llvm-config, I assume clang is also supported or being worked on.
That sort of patch is clearly fixing something that blocked him, and probably blocked many others who didn't get as far as trying to fix it.
A project should take on useful small patches, thats how you onboard contributors.
1 reply →
Is the project clearly documented as being written in GNU C++ rather than standard C++? If not, anything that's accidentally invalid C++ is fair game for bug fixes, is it not?
If all of these things are about making it build under clang though they need to better explain it or maybe group these changes together though.
My initial comment was maybe unfair but I can completely sympathise with the maintainers etc. that separately these PRs look like random small edits (e.g. from a linter) with no specific goal
Shouldn't small trivial changes be easier to review (and thus maybe even have higher prio)?
If there is a single maintainer of the project, sure.
If it's such a massively huge project like OpenJDK, then not really.
You might also check how non-trivial it is to get a change into the Linux kernel.