RFR: 8248411: [aarch64] Insufficient error handling when CodeBuffer is exhausted

[Andrew Dinn]

On Thu, 22 Oct 2020 16:36:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> So what about the `Foo* p` vs `Foo *p`? In short, I totally disagree. `Foo* p` supports the reading of `p` as Foo-pointer (or int-pointer, or void-pointer) which also emphasises the fact that the base type is vital to the operations available through/on `p`. This view is obscured by `Foo *p` (or `Foo p, *q`), suggesting "a pointer" is a more general concept, free of semantics imposed by its base type. For the same reason, I write `int* f()` not `int *f()`, not ever. And "we" don't write `int* p, q` nor do "we" write `int p, *q` since not only need pointers be initialised but more importantly, it's a truly bad idea to introduce different semantic entities in a single declaration. "We" write code to be read, and understood, by humans.
>> 
>> May I also offer the following explanation to why the `*` (pointer-decl) operator binds to the right. Is it perhaps due to the fact that the original K&R C-syntax predates the first official standard by roughly 20 years, syntax picked-up from the B language (which only had one "pointer type", the address of an array, and no type-system), that we use the unary prefix "indirection operator"; `*v` ?
>> 
>> In any case, I thank you both for reviewing the code (well, I guess 'aph' didn't actually review) even though it seems to upset the two of you, and despite the fact that I don't find the ranting particularly constructive.
>> 
>> Thanks also to Vladimir.
>
>> In any case, I thank you both for reviewing the code (well, I guess 'aph' didn't actually review) even though it seems to upset the two of you, and despite the fact that I don't find the ranting particularly constructive.
> 
> We're not upset, at least I'm not, but I don't think we should change existing code based on preference. In other words, despite the fact that I have a strong preference, I don't go round changing instances of `int* p` to `int *p` when I see them, and I don't think you should either. HotSpot doesn't have a history of micro-managing code layout, and that's a good thing. One consequence of this is minor local variations.
> 
> Also, churn is bad, and in this case we have a bunch of edits to a file which has nothing to do with the bug being fixed. It's taken me a while to be sure, but I can find no changes to opto/output.cpp except layout. This complicates the diffs for the reviewer and makes future diff searches harder for people in the future. Sure, if layout is unusual to the point of being misleading,we should change it.
> 
>> May I also offer the following explanation to why the * (pointer-decl) operator binds to the right. Is it perhaps due to the fact that the original K&R C-syntax predates the first official standard by roughly 20 years
> 
> The reason for the syntax is that Richie had the idea that "declaration follows use". http://www.gotw.ca/publications/c_family_interview.htm

Hi Patrick. You mistake my intention as well as Andrew's. I also am far from upset. The jist of my 'rant' was actually an argument, not an emotional reaction; the rant tags were merely offered by way of levity. I guess I actually need to reiterate the argument straight to address the concern both Andrew and I share.

My purpose was not to crusade against your preferred orthography with a complementary jihad (n.b. I am as agnostic about asterisk placement as I am about which end of a boiled egg to attack). The point I thought I had rendered clear (but clearly not clear enough) is that orthographic crusades to correct perceived errors across the code base are worse than futile. Offences to partisan pedantry aside, they serve to introduce noise into the code base, the result being to mask the all-important signal i.e. what changes were actually needed to fix an issue. That outcome is a red flag for any reviewer/maintainer not just because we have to decipher that signal at review time, but also because it is problematic 1) at backport time and 2) when debugging, diagnosing and fixing problems in the same or closely related parts of the code base and backporting their patches.

Of course, you are correct when you point out that this noise can be filtered in the github interface. However, that does not remove the noise from the code nor does it mean such redress is available from all the other tools -- including and most especially the human eye -- that have to process the code base when performing the review and susbequent review and maintenance tasks. Webrevs, file version diffs, git blame reports, conflict free patch backports all work better and require less human intervention if what are essentially irrelevant changes are avoided. That's advice that has been offered many times by other reviewers and that I repeat based on experience not ideology. I consider it far more valuable, albeit more boringly prosaic, than any conclusions one might arrive at debating the history of and intention behind K&R's syntactic choices.

-------------

PR: https://git.openjdk.java.net/jdk/pull/765