Foreign.C.Error.errnoToIOError should use strerror_r, not strerror

[bgamari]

strerror is not in general thread-safe and therefore cannot be reliably used in Haskell programs. POSIX.1-2001 provides strerror_r, which is reentrant while providing similar semantics. On Windows we must rather use stderror_s. Foreign.C.Error.errnoToIOError should use these not strerror.

See GHC #24344.

[Bodigrim]

The MR is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11984. Once CI is green, I intend to trigger a vote so that we have a chance to fix it in time for GHC 9.10.

[bgamari]

It would be appreciated if we could bring this to a vote as I don't imagine that the approach is going to fundamentally change at this point.

[Bodigrim]

@bgamari I made an exception for the series of exception backtraces proposals, but in general we strive to vote on a finished MR so that there are less surprises afterwards. Please ping me once CI gets green.

[bgamari]

The MR is now passing.

[tomjaguarpaw]

+1

---

This seems very sensible

[phadej]

Looking at the change I wonder whether this is exactly a change one should not need to ask CLC about?

The readme of this repository says:

The ownership of base belongs to GHC developers, and they can maintain it freely without CLC involvement as long as changes are invisible to clients.

[Bodigrim]

Dear CLC members, let's vote on the proposal to implement Foreign.C.Error.errnoToIOError via strerror_r instead of strerror, which provides for better thread safety. The MR is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11984. This is not a breaking change.

@hasufell @mixphix @velveteer @angerman @parsonsmatt

---

+1 from me.

[velveteer]

+1

[bgamari]

Looking at the change I wonder whether this is exactly a change one should not need to ask CLC about?

That was my feeling as well; however, out of deference to the committee I asked and @Bodigrim advised to open a proposal.

[mixphix]

+1

[phadej]

Looking at the change I wonder whether this is exactly a change one should not need to ask CLC about?

That was my feeling as well; however, out of deference to the committee I asked and @Bodigrim advised to open a proposal.

This sets a precedence that virtually any change to base have to go through CLC.

In particular, I don't think that

The ownership of base belongs to GHC developers

is true. There cannot be responsibility without power.

[Bodigrim]

The change affects visible behavior of base, ergo falls under CLC purview.

If there is an interest in a meta discussion, please open a separate issue.

[hasufell]

+1

[Bodigrim]

Thanks all, that's enough votes to approve.