Std.os function namespace changes, or a wonky lsp?

Help
,
1

I made a quick udp-based echo server to see if zig could fit some basic requirements for a project. I see a lot of examples online doing std.os.socket(..) or std.os.recvfrom(...).

In my editor (neovim), I end up having to do std.os.linux.socket(...). I’m wondering if there were any changes to how the os part of the standard library was namespaced? I’m assuming my lsp or plugin is issue, but wanted to check with you all first to see if there’s any ideas.

Thanks

2

Using something like os.recvfrom(...) results in a compiler error, but then I see code like this: focus/lib/focus.zig at 2328def3ad59557361335f2e03d03d265d5399df · jamii/focus · GitHub.

3

A lot of std.os was moved to std.posix recently if you’re using a v0.12 from the past couple of weeks.

This includes functions like open() and recv().

It should be a pretty easy one-for-one swap to get most of the older std.os examples going though. Hope that helps!

3 Likes
4

This is exactly what I was hoping to hear. Thanks!

2 Likes
5

I was hit by this these days too. I call it posix-gate. lol

9 Likes
6

Hit by it too. Hard. All the constants too. Still running into code I don’t want to add anything to because I don’t want to have to redo everything on a recompile.

1 Like
7

I would place posix compliant syscalls under os.posix and OS-specific syscalls under os.<os-name>

8

Best course of action for std.os replacement is to search for the function in the 0.12.0 documentation.

Some functions, like exit, have cross platform replacements: std.process.exit

If you cannot find the function elsewhere (at least std.process and std.fs), use the std.posix call.

If you decide to use a call in a different package, check the compatibility of the return value. std.os in 0.11.0 converts errno error codes in zig errors.

2 Likes
9

maybe std.posix should be std.unix since it is easier to build a compat layer for them and then have a std.windows. given mac’s unix heritage not sure where that fits. put linux, freebsd, etc under std.unix;

if you want cross platform you use std.fs and the like. If you want general unix and don’t care about windows, use std.unix. simiar for windows.

if you want to do something special but it isn’t supported by the zig layer you are probably writing to std.unix and std.windows with some comptime logic in your code.

if you want to do something highly specific (io_uring, kqueue, IOCP) yo are writing to std.unix.linux, std.unix.freebsd, std.windows.

that makes the most sense to me.

(if you want to have a very clean hierachy unix/windows go under std.os.unix/windows. std.os might just be code to test what os you are on, get defaults for them etc… but no platform specific code. that all goes under std.os).

1 Like