Rename BOX3D_FIXED_SATURATE to FIX_SATURATE, and fix three comments - #4
Merged
Conversation
… the library The prefix sweep missed this one, and so did my residue check: I grepped for b3*/B3_* and filtered out anything matching "box3d", which is exactly the pattern that hides a macro named BOX3D_FIXED_SATURATE. An unfiltered sweep found it plus three BOX3D_LUDICROUS_MODE mentions -- those three are provenance COMMENTS naming box3d's real flag, which is correct and stays. This one is not a comment. It is a live compile option this library exposes under another project's name. box3d keeps its own BOX3D_FIXED_SATURATE spelling: its compatibility header passes the flag down, the same direction it already hands down FIX_API and FIX_ASSERT. Nothing changes for box3d. Default builds are unaffected -- the macro is undefined by default, so both frozen hashes are unchanged (core 0x3e1c7997594d2019, wide 0xeedc16ea642ffb5f), 6/6 green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The rename rewrote b3* inside COMMENTS as well as code. Two of those were references to box3d's own symbols, not to anything here, so the header ended up naming `fixShapeDistance` and `fixRayCastInput` -- functions and types that do not exist in this library and never will. Restored to their real box3d names. Found by generating box3d's compatibility header from the rename map and compiling it: `typedef fixShapeDistance b3ShapeDistance;` failed with "unknown type name", because a comment reference had been promoted into the map as though it were an export. A rename map built from a grep of identifiers cannot tell code from prose; compiling the result can. The third fix is drift rather than corruption. A block listing what had NOT been extracted still said the position and bounds validators "cannot move until the narrow/wide design fork is resolved" -- but that fork IS resolved and they moved in the previous PR. It was describing a world that no longer exists while remaining perfectly readable, which is how a stale comment survives review. Both frozen hashes unchanged, 6/6 green: comments only. Co-Authored-By: Claude Opus 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.
Two small corrections, both found by trying to use the library rather than by reading it.
BOX3D_FIXED_SATURATE->FIX_SATURATEThe last box3d name in the library, and my residue check is why it survived: I grepped for
b3*/B3_*and filtered out anything matchingbox3d— which is exactly the pattern that hides a macro calledBOX3D_FIXED_SATURATE. An unfiltered sweep found it plus threeBOX3D_LUDICROUS_MODEmentions; those three are provenance comments naming box3d's real flag, which is correct and stays. This one is a live compile option exposed under another project's name.box3d keeps its own spelling — its compatibility header hands the flag down, the same direction it already hands down
FIX_APIandFIX_ASSERT. Nothing changes for box3d.Three comments
The rename rewrote
b3*inside comments as well as code. Two were references to box3d's own symbols, so the header ended up namingfixShapeDistanceandfixRayCastInput— a function and a type that do not exist here and never will.Found by generating box3d's compatibility header from the rename map and compiling it:
A rename map built from a grep of identifiers cannot tell code from prose. Compiling the result can.
The third is drift rather than corruption: a block listing what had not been extracted still claimed the position and bounds validators "cannot move until the narrow/wide design fork is resolved" — but that fork is resolved and they moved in #2. It described a world that no longer exists while staying perfectly readable, which is how a stale comment survives review.
Verification
Default builds are unaffected —
FIX_SATURATEis undefined by default and the rest is comments. Both frozen hashes unchanged (0x3e1c7997594d2019,0xeedc16ea642ffb5f), 6/6 green.