#std.os.linux question (open/ftruncate)

1 messages · Page 1 of 1 (latest)

half star
#

Since I've been sporadically updating with zig-bootstrap, I went back to fix and work on one of my older projects. I noticed in the code I'm working on std.os.open and similar have been removed. I decided to just move to the specific functions for std.os.linux.open [1], but between that and std.os.linux.ftruncate [2] the return type of open is usize, and the input of ftruncate takes an i32. Is there any way to handle this correctly, or is this a bug?

I assume I can just do @as(std.os.linux.fd_t, @bitCast(@as(u32, @intCast(open_result)))) since by spec linux open should only return an int [3] and the source seems to agree [4].

Curious what others think before I make an issue for it.

[1] https://github.com/ziglang/zig/blob/master/lib/std/os/linux.zig#L1095
[2] https://github.com/ziglang/zig/blob/master/lib/std/os/linux.zig#L985
[3] https://man7.org/linux/man-pages/man2/open.2.html
[4] https://github.com/torvalds/linux/blob/master/fs/open.c#L1417

#

std.os.linux question (open/ftruncate)

sand wren
#

Don’t really have any answer for you . But the source code of the c open call does return a long which would be an isize so neither usize or int right?

half star
#

I think i32 should be correct in that case since long is also a signed 32 bit number. isize I think is a signed 64 bit number which would match with long long.

#

Sorry just realized my response didn't make sense, just fixed it.

sand wren
#

I think long is a weird type that actually should change size based on the system size so basically isize.

#

But usize definitely does seem wrong because that is definitely larger than all of the sizes Linux uses.

half star
#

Oh excuse me, I've been in windows land to long. I assumed it was the same on linux. long on windows seems to still be 32 bits regardless of x86 or x64. I try and stick away from those types in most cases so I never noticed the discrepancy.

#

I think I might have gotten it mixed up with a blog post I read about intmax_t not being updated to 128bits even when though modern 64 bit machines can handle it.
https://thephd.dev/intmax_t-hell-c++-c

The Pasture
A Special Kind of Hell - intmax_t in C and C++

C and C++ as languages have a few things separating them from each other, mostly in their minute details and, occasionally, larger feature sets like designated initializers. But there is a disturbingly high amount of C++ that can simply do C’s job far better than C

#

Oh I just did a bisect and I think I found my fix.

#

Just have to use std.posix instead of std.os, it doesn't fix the discrepency, but the functions I was using before seem to have just been moved.

sand wren
#

Yeah I think the high level wrapper around that is actually in std.fs

#

Or rather the plattform independent wrapper