How do I access Environ from a dynamically loaded library (.so)?

Help
1 
comptime {
    @export(&NapiRegistrationEntry, .{ .name = "napi_register_module_v1", .linkage = .strong });
}

// This is my entry point.
// It is invoked by Node.js during addon instantiation.
// It can't have the "init" parameter with Environ:
fn NapiRegistrationEntry(env: napi.napi_env, exports: napi.napi_value) callconv(.c) napi.napi_value {
  // ?? How do I access Environ here?
}

It appears that std.process.getEnvMap/getEnvVarOwned have vanished in 0.16?

2

Link to libc and use the same global environment that you would in C.

3

Not going to work for me because I need to feed it into the new `std.process.spawn`, which requires that I pass a pointer to Environ.Map.

4

On POSIX/linked with libc, zigs environ implementation works over the same data that libc does. You can just create a zig environ from libc’s

extern "c" const environ: [*:null]const ?[*:0]const u8;

pub fn main(init: std.process.Init) !void {
    {
        var map = try init.minimal.environ.createMap(init.gpa);
        defer map.deinit();
        var iter = map.iterator();
        std.debug.print("zig\n", .{});
        while (iter.next()) |e| {
            std.debug.print("{s}={s}\n", .{ e.key_ptr.*, e.value_ptr.* });
        }
    }
    {
        const env: std.process.Environ = .{ .block = .{ .slice = std.mem.sliceTo(environ, null) } };
        var map = try env.createMap(init.gpa);
        defer map.deinit();
        var iter = map.iterator();
        std.debug.print("c\n", .{});
        while (iter.next()) |e| {
            std.debug.print("{s}={s}\n", .{ e.key_ptr.*, e.value_ptr.* });
        }
    }
}
1 Like
5

Thank you, that’s indeed a working workaround for POSIX! And for Windows I’ll have to re-do what Environ already does on Windows? What’s the point then of even having Zig’s std if it cannot be used? Let’s just ship bindings for libc and be done with it.

It worked just fine in 15.2, one release ago.

6

Windows is even easier since it being global is a windows side thing, unlike POSIX. std.process.Environ{ .block = .global }.

you can use zig std, It’s just not as easy. That is intentional!
Being able to access the environment globally is hidden control flow and can introduce foot guns.

On master, zig finally implemented “juicy main”. That is, you can ask for a bunch of goodies as a parameter to main instead of setting them up yourself (see the code I sent earlier).

zig took that opportunity to make environment variables and process args have a non-global API (may still be global behind it ofc) and favour passing them around like you already do with allocators and (on master) Io. And ofc you can easily get them via juicy main, but not so easily anywhere else.

The idea being you should just take a parameter/field instead of using the environment, if the caller wants to get the value from the environment they can do that themselves.

why do you need zigs environ when napi provides its own?

I should mention that there is Environ.empty if you need one but dont care about the actual values.

1 Like