Correct four safety explanations that overstated or contradicted the code - #129
Merged
Merged
Conversation
…code SAFETY.md said that a failed required step never installs converted output, but a failure to mark the recovery record complete happens after installation and is reported with the replacement committed. It also advised -From utf-16le or utf-16be in the BOM-less UTF-32 section; that advice belongs to UTF-16, and the UTF-32 section now names utf-32le and utf-32be, which EC resolves. Two comments were stale: an unchanged file is not rewritten but is still read and validated in full, and detection runs even when the source is chosen explicitly, so a null detected codec means detection identified none. Wording only; no behaviour changes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Wording only; no behaviour changes.
docs/SAFETY.md, install sequence: "If a required step fails, EC does not install converted output" also appeared to cover step 9 (marking the recovery record complete). That step runs after installation:EncodingConverter.cs:601returnsRecoveryRecordErrorwithReplacementCommitted = true. The text now says a failure before step 8 leaves the source unchanged, and a step 9 failure leaves verified converted output installed with thePreparedrecord.docs/SAFETY.md, UTF-16/UTF-32: the-From utf-16le/utf-16beadvice sat in the BOM-less UTF-32 section. It moved to the UTF-16 section; the UTF-32 section now namesutf-32leandutf-32be.ConversionPolicy.cs: "An unchanged file is not read or rewritten" was stale. It is not rewritten, but it is read and validated in full afterwards.ConversionMetadata.cs: a CLI-Fromrun is not an example of detection not running. Detection still runs for explicit sources, so null means detection identified no codec.Verification
utf-32leandutf-32beresolve (toutf-32andutf-32BE). Against a BOM-less UTF-32LE file with-WhatIf: no-Fromexits 5,-From utf-32leexits 0,-From utf-32beexits 3 (decode error).🤖 Generated with Claude Code