Skip to content

Enable specs for close_on_exec on Windows#14716

Merged
straight-shoota merged 4 commits intocrystal-lang:masterfrom
straight-shoota:spec/close_on_exec-win32
Aug 13, 2025
Merged

Enable specs for close_on_exec on Windows#14716
straight-shoota merged 4 commits intocrystal-lang:masterfrom
straight-shoota:spec/close_on_exec-win32

Conversation

@straight-shoota
Copy link
Member

These specs be enabled on Windows as well to ensure the expected behaviour (even though there's no mechanism for changing the value).

@ysbaddaden
Copy link
Collaborator

Looks good, but I would wait a bit for #14717 to decide if we change the default (IMO: we should) and do it in one go.

@straight-shoota
Copy link
Member Author

straight-shoota commented Jun 17, 2024

I'd actually prefer to merge this first, and then the PR for #14717 on top. That way the effective change in behaviour will be explicitly documented in the spec changes.

Also there's really no reason to postpone this addition. It's merely enabling specs for current behaviour. And as such is a different concern than changing behaviour.

Copy link
Collaborator

@ysbaddaden ysbaddaden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you want.

We could consider the current behavior to be faulty: enabling the specs fails on Windows because the default there is false, so for the specs to pass and be correct, the behavior must change (aka: fix the implementation, not the spec) :)

@straight-shoota straight-shoota added this to the 1.18.0 milestone Aug 11, 2025
@straight-shoota straight-shoota merged commit dac18a8 into crystal-lang:master Aug 13, 2025
39 checks passed
@straight-shoota straight-shoota deleted the spec/close_on_exec-win32 branch August 13, 2025 09:29
straight-shoota added a commit that referenced this pull request Aug 17, 2025
`#system_close_on_exec=` (and thus `#close_on_exec=`) returns `Nil` on Windows. But #15698 added a type-restriction to `Bool`. We didn't notice this discrepancy before, because this method was never called on Windows until we enabled the specs for that in #14716.

Changing the return value to `false` on Windows should be the correct behaviour. If the parameter is `true`, the method raises.

This is a classic integration issue. It could've been avoided by testing each change against current master directly before merging it. But luckily they are pretty rare, so there's no urgent need to do something about it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants