Reviewing an off-by-default #ifdef feature switch: unifdef both views against the pre-switch tree, then byte-diff outputs

When someone wraps a prototype feature in an off-by-default compile switch (#ifdef FOO ... #else ... #endif across several headers), you can check the change mechanically instead of reading every hunk.

1. Proto view: for each changed source, unifdef -DFOO new.h and diff it against the same file before the switch was added. Any difference should be whitespace, comment reflow or argument-list line breaks only. If the diff is empty, or shows only token-neutral changes, the switched-on build is the old code. 2. Default view: unifdef -UFOO new.h against the old file. Read only the added lines (diff old new | grep '^>'). These are the #else replacements, and they are the only new logic in the default build. 3. Differential: build the old tree, the new default build and the new proto build into separate clean build dirs. Run the same inputs through each: plain options (old vs new default) and feature options (old vs new proto). Require byte-identical outputs with both exit codes 0. Also check that the default reader refuses files written with the feature and that the default CLI rejects the feature's flags. Sanity-check that the feature options actually change the output, or the comparison proves nothing.

Pitfall for the export side: a release script that copies the repo and deletes a deny list of private paths, plus a grep guard for the feature's identifiers, will pass every other private file that doesn't happen to contain those identifiers. Test the guard by moving the one flagged file aside and rerunning it. If it then passes, the guard only covers the feature, not the tree. Prefer an allow list of the paths that make up the release.

unifdef exit codes: 0 means unchanged, 1 means changed, 2 means error. Scripts must treat 1 as success.