On windows, `HANDLE` type values are converted to `syncio.FileHandle` in
`lib/std/syncio.nim`, `lib/pure/memfiles.nim` and `lib/pure/osproc.nim`.
`HANDLE` type is `void *` on Windows and its size is larger then `cint`.
https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
This PR change `syncio.FileHandle` type so that converting `HANDLE` type
to `syncio.FileHandle` doesn't lose bits.
We can keep `FileHandle` unchanged and change some of parameter/return
type from `FileHandle` to an type same size to `HANDLE`, but it is
breaking change.
As said in the warning after #21659, a set of ints defaults to
`set[range[0..65535]]` which is very large. So in osproc, a `case`
statement is used instead of an int set to check for an int being one of
2 values.
Also tested all of CI with the warning from #21659 as an error, this
seems to be the only remaining case in CI.
#23992 The test case provided does not cover the Windows situation, I
fixed it in this new PR.
Fixed an issue where errorCode was always 0 when startProcess didn't use
the poEvalCommand flag.
Tthe sleep command might not be available in all Windows installations,
so I skipped the relevant test.
Added a test case, tested on my fedora and windows systems.
a warning message been added to the documentation to remind users that the timeout parameter is expressed in milliseconds, not seconds. to help prevent confusion and unexpected behaviours.
The Nim manual says that an implicit conversion to cstring will
eventually not be allowed [1]:
A Nim `string` is implicitly convertible to `cstring` for convenience.
[...]
Even though the conversion is implicit, it is not *safe*: The garbage collector
does not consider a `cstring` to be a root and may collect the underlying
memory. For this reason, the implicit conversion will be removed in future
releases of the Nim compiler. Certain idioms like conversion of a `const` string
to `cstring` are safe and will remain to be allowed.
And from Nim 1.6.0, such a conversion triggers a warning [2]:
A dangerous implicit conversion to `cstring` now triggers a `[CStringConv]` warning.
This warning will become an error in future versions! Use an explicit conversion
like `cstring(x)` in order to silence the warning.
However, some files in this repo produced such a warning. For example,
before this commit, compiling `parsejson.nim` would produce:
/foo/Nim/lib/pure/parsejson.nim(221, 37) Warning: implicit conversion to 'cstring' from a non-const location: my.buf; this will become a compile time error in the future [CStringConv]
/foo/Nim/lib/pure/parsejson.nim(231, 39) Warning: implicit conversion to 'cstring' from a non-const location: my.buf; this will become a compile time error in the future [CStringConv]
This commit resolves the most visible `CStringConv` warnings, making the
cstring conversions explicit.
[1] https://github.com/nim-lang/Nim/blob/d2318d9ccfe6/doc/manual.md#cstring-type
[2] https://github.com/nim-lang/Nim/blob/d2318d9ccfe6/changelogs/changelog_1_6_0.md#type-system
* fixes#18858 [backport]
* ensure async tests work with --experimental:strictEffects [backport]
* ensure async tests work with --experimental:strictEffects [backport]
* Fix#14906 by wrapping outputStream with PipeOutStream
* Fix compile error when ./build_all.sh
* Use PipeOutStream on posix
* Fix compile error when build_all.sh
* Use ptr UncheckedArray
* Replace copyRefObj
* Remove tmp buffer from posPeekData
* Add more tests for outputStream
* Add comments about PipeOutStream.buffer
* Fix bug in posReadLine
* Move implementation of newPipeOutStream to streamwrapper module
* osproc: move fork-based code path under the when conditional
* osproc: avoid using the environ global on Haiku
* osenv: import environ from stdlib.h on Haiku
Haiku's environ is declared in `<stdlib.h>` by default, differing from
POSIX and/or Linux. Import it from there to avoid collision with anyone
importing `<stdlib.h>` from Nim.
