the target is named by mcpp, not borrowed from Cygwin - #41
Merged
Merged
Conversation
`bits/setjmp.h` sizes `jmp_buf` by whether the target is Windows, because
that decides the calling convention. It asked `__CYGWIN__`, which answered
correctly only by accident: mcpp kept that name defined because nothing else
named the target, while upstream code reads it as "Win32 is available" --- a
30-member measurement found four packages doing exactly that and reaching
`#include <windows.h>`. A BORROWED NAME MEANS WHAT THE LENDER'S HISTORY MADE
IT MEAN.
mcpp 2026.9.21.1 states the fact under its own name,
`__mcpp_target_<os>__`, for every target. This header reads that first and
still accepts `__CYGWIN__`, so it is correct on an engine from either side of
that release --- the new name is absent before it, the old one is withdrawn
after a later one. The second operand is there so this file has no flag day,
not for redundancy, and goes once the withdrawal ships.
VERIFIED BY A CRITERION THAT FAILS ON THE OLD HEADER. A translation unit
asserting `sizeof(jmp_buf) >= 32 * sizeof(unsigned long long)`, built for
`x86_64-windows-gnu` with `-U__CYGWIN__ -U__CYGWIN32__` to simulate the
withdrawal:
published 0.18.0 static assertion failed: did not take the Windows branch
this branch passes
The failing side is what this change is for, and it is the silent kind: the
old header falls to `#include_next` and produces a SHORT record, which this
file's own comment describes as "a mismatch nothing reports until the record
overruns". An earlier run of the same simulation without the assertion
reported success, because a short `jmp_buf` compiles and links perfectly well.
The header change in this branch is what the version names: `bits/setjmp.h` reads mcpp's own name for the target and still accepts the borrowed one, so that a later mcpp release may withdraw `__CYGWIN__` without this package falling silently to a shorter record. Backward compatible in both directions by construction. On the engine published today the new name is absent and the old operand answers; on 2026.9.21.1 both are present. Neither ordering of the two releases breaks a build, which is the property the three-step sequence exists to hold.
Project-owned macros are upper case --- `NDEBUG` and every other one are --- while lower case belongs to the compiler's own predefines (`__linux__`), which mcpp supplies but does not own. 2026.9.21.1 spelt it lower; the release that withdraws `__CYGWIN__` renames it in the same change, so this header is written against the spelling it will keep. THE LOWER-CASE NAME IS NOT READ HERE AND DOES NOT NEED TO BE. It existed for one release and nothing consumed it. Two operands cover every engine: one up to and including 2026.9.21.1 defines `__CYGWIN__`, and the one that withdraws it defines `__MCPP_TARGET_WINDOWS__`. No engine defines neither, so this header has no flag day and the two releases may land in either order --- which is the point of the second operand, not redundancy. It goes once the withdrawal has shipped.
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.
What changes
port/include/bits/setjmp.hsizesjmp_bufby whether the target is Windows — that decides the calling convention, and so the size of the register save area. It asked__CYGWIN__.That name answered correctly only by accident. mcpp kept it defined because nothing else named the target, while upstream code reads it as "Win32 is available" — a 30-member measurement found four packages doing exactly that and reaching
#include <windows.h>. A borrowed name means what the lender history made it mean.mcpp 2026.9.21.1 states the fact under its own name,
__mcpp_target_<os>__, for every target. This header now reads that first and still accepts__CYGWIN__, so it is correct on an engine from either side of that release. The second operand exists so this file has no flag day, not for redundancy, and goes once the withdrawal ships.Verified by a criterion that fails on the old header
A translation unit asserting
sizeof(jmp_buf) >= 32 * sizeof(unsigned long long), built forx86_64-windows-gnuwith-U__CYGWIN__ -U__CYGWIN32__to simulate the withdrawal:static assertion failed: bits/setjmp.h did not take the Windows branchThe failing side is the point, and it is the silent kind. The old header falls to
#include_nextand produces a SHORT record — which this file own comment describes as "a mismatch nothing reports until the record overruns". An earlier run of the same simulation without the assertion reported success, because a shortjmp_bufcompiles and links perfectly well.Sequence
__mcpp_target_<os>__(additive)__CYGWIN__Step 3 taken first would leave every published copy of this header falling to its
#else.