std.process.Child
is not useable for Linux libraries not linking libc even when an env_map
is provided.
#23372
Labels
bug
Observed behavior contradicts documented or intended behavior
standard library
This issue involves writing Zig code for the standard library.
Milestone
Zig Version
0.14.0
Steps to Reproduce and Observed Behavior
Given
example.zig
:Try:
Expected Behavior
See https://github.com/ziglang/zig/pull/7553/files#r2014522673 where the originating issue is identified in a 2020 change. The same code exists today though:
zig/lib/std/process/Child.zig
Lines 591 to 611 in b4b1daf
It seems like the compile error is too aggressive, disallowing legitimate use of the Child API by passing in a hand crafted
env_map
. Presumably the else branch could even optimistically usestd.os.environ
since it can be set by things other than the zig start code used for exes. In my case, I actually do this! I naively tried passing in env_map though to work around, and then realized what I thought was a compiler bug handling mixed comptime-known / runtime-known if / else branches was actually correct compiler behavior - this just appeared to be an API decision. I'm hoping that decision can be changed to make this API more widely usable.I'm happy to take this issue up if the idea of populating env from
std.os.environ
sounds reasonable. Perhaps paired with stdlib docs updates to point out the caveats. I guess this would require an API for setting std.os.environ since its status is currently inherently ambiguous via undefined instead of optional. Maybe a paired bool flag to indicate it was populated by startup code? Or, if breaking existing users is OK, maybe just switch to an optional since std.os.environ truly is optional.The text was updated successfully, but these errors were encountered: