Applications supplying their own custom stack to pthread_create are not
allowed to free the allocated memory after pthread_join returns as,
according to the specification, the thread is not guaranteed to be dead
after the join call returns.
Avoid this class of problems by avoiding the use of a custom stack
altogether, let pthread handle its own resources.
Allocations made on the child stack are now done on the C heap.
Thanks @semarie for noticing the problem on OpenBSD and suggesting a
fix.
Closes#7275
commit 9d1816111d used the "output path"
as the path for passing shared library artifact paths to the Zig CLI.
For Windows, this was incorrect because it would pass the .dll instead
of the .lib file. This commit passes the "output lib path" instead,
which makes it pass the .lib path in case of a .dll on Windows.
This way the linker does not complain and say, "bad file type. Did you
specify a DLL instead of an import library?"
stderr_mutex may still be held when we reach the signal handler, grab
our own stderr handle to print the error messages and avoid deadlocking.
Closes#7247
Make it behave like the read() wrapper for unix systems.
Reading the whole buffer breaks some use-cases like buffered readers
over sockets.
Closes#7121
This intentionally diverges from the unix dirname command, as well as
Python and Node.js standard libraries, which all have this edge case
return the input path, unmodified. This is a footgun, and nobody should
have ever done it this way.
Even the man page contradicts the behavior. It says:
"strip last component from file name". Now consider, if you
remove the last item from an array of length 1, then you
have now an array of length 0. After you strip the last component, there
should be no components remaining. Clearly, returning the input parameter
unmodified in this case does not match the documented behavior. This is
my justification for taking a stand on this API design.
closes#6746closes#6727closes#6584closes#6592closes#6602
As documented in the comment right above the finalization function,
Gimli can be used as a XOF, i.e. the output doesn't have a fixed
length.
So, allow it to be used that way, just like BLAKE3.
