[Cfp-interest 3361] Re: [SC22WG14.28105] Errors in N3435 changes

[Joseph Myers]

On Mon, 20 Jan 2025, Jim Thomas wrote:

> Reviewing the changes in N3435 for CFP proposals, I found these place below where changes were not fully and correctly applied:  
> 
> N3291
> 7.24.1.5#4 (N3220) now 7.24.2.6#4 (N3435): The replacement of “decimal floating-point number” with “decimal form” and the replacement of “hexadecimal floating-point number” with “hexadecimal form” were not done.

See https://gitlab.gwdg.de/iso-c/draft/-/merge_requests/495 - I hope that 
addresses that issue.

> 
> N3324
> 7.12.2#3: The parenthetical phrase “(also known as a singularity or infinitary)” is to be removed. In “the mathematical log() function” the “log()” should not be in code typeface. (Code typeface for “log(0.0)” is correct.)

See https://gitlab.gwdg.de/iso-c/draft/-/merge_requests/499 for the log 
fix (starting from Robert's editorial fix from Minneapolis not to use 
parentheses, but I also removed the fixed-width font as inappropriate).

I didn't include the removal of the parenthetical phrase since I was 
guessing the omission of that was deliberate, but if it's supposed to be 
removed then that can of course be done in a separate MR.

Maybe we need commit practices designed to facilitate review more readily, 
so we don't need to guess what was or was not intentional:

* Each commit only ever implements changes from exactly one accepted paper 
(or exactly one NB comment or group of NB comments for the same issue, 
when dealing with such issues at ballot stage).  If a mistake is 
discovered in the application of a previous paper, or a pre-existing issue 
is discovered in the standard, that fix should always go in a separate 
commit.  (If the mistake is discovered *before* the commit in question is 
merged to main, the prior commit can be fixed up with an interactive 
rebase.  Once commits are in main, there should of course be no more 
rebasing of those commits.)

* If a commit differs from the exact changes from the paper, the intended 
differences should be explicitly called out in the commit message, so that 
we can know that any other differences are unintentional.  That includes 
all reasons for applying a change different from what's in the paper, 
beyond the routine updates of Annex J / Annex M / cover sheet that always 
apply (change was accepted with specified differences; editorial / English 
usage issues with paper found in the course of applying it; changes needed 
to resolve conflicts with other accepted changes).

* Reformatting of otherwise unmodified sources should not be combined with 
any change that has visible effects on the output, so a substantive change 
should only affect the minimum number of lines of LaTeX source needed to 
achieve its effect.

-- 
Joseph S. Myers
josmyers at redhat.com