GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:14:07Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15134enumFrom... aren't really documented.2019-07-07T18:14:07ZDavid FeuerenumFrom... aren't really documented.The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------...The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"enumFrom... aren't really documented.","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1AzelAzelhttps://gitlab.haskell.org/ghc/ghc/-/issues/12012Socket operations on Windows check errno instead of calling WSAGetLastError()2019-07-07T18:27:59ZenolanSocket operations on Windows check errno instead of calling WSAGetLastError()Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't unders...Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't understand it very well.
The upshot here is that every error message originating from Winsock is wrong. Nobody noticed since any error used to just crash your program (#12010).
Here's some MinGW documentation http://oldwiki.mingw.org/index.php/sockets and something from MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ms740121%28v=vs.85%29.aspx
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Socket operations on Windows check errno instead of calling WSAGetLastError()","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't understand it very well.\r\n\r\nThe upshot here is that every error message originating from Winsock is wrong. Nobody noticed since any error used to just crash your program (#12010).\r\n\r\nHere's some MinGW documentation http://oldwiki.mingw.org/index.php/sockets and something from MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ms740121%28v=vs.85%29.aspx","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1AzelAzelhttps://gitlab.haskell.org/ghc/ghc/-/issues/10412isAlphaNum includes mark characters, but neither isAlpha nor isNumber do2019-07-07T18:36:02ZArtyom.KazakisAlphaNum includes mark characters, but neither isAlpha nor isNumber do```hs
> isMark '\768'
True
> isAlphaNum '\768'
True
> (isAlpha '\768', isNumber '\768')
(False,False)
```
This behavior comes from this piece in WCsubst.c:
```
unipred(u_iswalnum,(GENCAT_LT|GENCAT_LU|GENCAT_LL|GENCAT_LM|GENCAT_LO|
...```hs
> isMark '\768'
True
> isAlphaNum '\768'
True
> (isAlpha '\768', isNumber '\768')
(False,False)
```
This behavior comes from this piece in WCsubst.c:
```
unipred(u_iswalnum,(GENCAT_LT|GENCAT_LU|GENCAT_LL|GENCAT_LM|GENCAT_LO|
GENCAT_MC|GENCAT_ME|GENCAT_MN|
GENCAT_NO|GENCAT_ND|GENCAT_NL))
```
I'm not sure what should be done here. Is it a bug with isAlpaNum? Or with isAlpha? How does it correspond to iswalnum's behavior in C++?
(And if it's a feature and not a bug, then it should definitely be documented.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"isAlphaNum includes mark characters, but neither isAlpha nor isNumber do","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":["unicode"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"{{{#!hs\r\n> isMark '\\768'\r\nTrue\r\n\r\n> isAlphaNum '\\768'\r\nTrue\r\n\r\n> (isAlpha '\\768', isNumber '\\768')\r\n(False,False)\r\n}}}\r\n\r\nThis behavior comes from this piece in WCsubst.c:\r\n\r\n{{{\r\nunipred(u_iswalnum,(GENCAT_LT|GENCAT_LU|GENCAT_LL|GENCAT_LM|GENCAT_LO|\r\n\t\t GENCAT_MC|GENCAT_ME|GENCAT_MN|\r\n\t\t GENCAT_NO|GENCAT_ND|GENCAT_NL))\r\n}}}\r\n\r\nI'm not sure what should be done here. Is it a bug with isAlpaNum? Or with isAlpha? How does it correspond to iswalnum's behavior in C++?\r\n\r\n(And if it's a feature and not a bug, then it should definitely be documented.)","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1AzelAzel