ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
errpr has quit [Ping timeout: 252 seconds]
Sahnvour has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
jmiven has quit [Quit: co'o]
jmiven has joined #zig
<suirad>
andrewrk: what minimal windows do you plan on zig targeting? I was considering doing the windows portion of std.mutex and was reading over the various api to use.
<suirad>
its looking like for winxp: CriticalSections; for winvista-win7: SRWLocks; and for win8+: WaitOnAddress since its the closest thing to a futex. But those I have found before digging into documented/undocumented winnt stuff.
<emekoi_>
i was working on porting std.Muted to windows, but i didn't consider the different versions of windows
emekoi_ has quit [Ping timeout: 256 seconds]
oconnor0 has quit [Quit: Quit]
_whitelogger has joined #zig
<daurnimator>
re: the pointer subtraction issue: how do you get the "array size" of a type in zig
<daurnimator>
e.g. if an object has size 3 but alignment 2. then it takes up 4 bytes per item in an array, right?
<MajorLag>
arrays don't have "specially" aligned elements. @sizeOf(u24) is 3, and @alignOf(u24) is 4. @sizeOf([10]u24) is 40. You can't declare [10]align(2) u24, it'll be a compile error.
<MajorLag>
oh, interesting. andrewrk: this violates the @alignOf(T) <= @sizeOf(T) rule.
<MajorLag>
as stated anyway, I'm pretty sure it is doing what's intended, it just isn't documented correctly?
<suirad_>
emekoi_: what api were you going to use for it?
<daurnimator>
MajorLag: huh? isn't the rule the other way around?
<daurnimator>
MajorLag: from @alignOf docs: " The result is a target-specific compile time constant. It is guaranteed to be less than or equal to @sizeOf(T). "
<MajorLag>
right, and @alignOf(u24) is 4, but @sizeOf(u24) is 3. 4 > 3.
<daurnimator>
MajorLag: would depend on the system. some probably have 1, some will have 2, others may have 4
<MajorLag>
right, but the fact that it violates the rule on any machine means the guarantee is not a guarantee.
<daurnimator>
yup
<daurnimator>
so sounds like we need to do work there
<daurnimator>
going back to my question though: how *do* I get the array index of an item given a pointer to it and the base??
<MajorLag>
`const item_index = (@ptrToInt(item_ptr) - @ptrToInt(base_ptr)) / @alignOf(ItemType);` I guess? Since you can't have a custom alignment of array items, @alignOf() will be the "natural" alignment.
<daurnimator>
MajorLag: even though the docs say align might be < sizeof?
<MajorLag>
hmm....
<MajorLag>
boy, having to add a math.max in there...
<daurnimator>
isn't not even math.max
<daurnimator>
wouldn't it be the lowest multiple of alignOf larger than sizeOf?
<MajorLag>
yeah, I guess it would be.
<daurnimator>
In C we solve this by using pointer subtraction :P but here I'm trying to emulate pointer subtraction in zig.
<daurnimator>
MajorLag: is it valid in zig to do base_ptr[1] if the array is only 1 long?
<daurnimator>
or are you saying to do it on the base ptr case to [*]?
<daurnimator>
*cast
<MajorLag>
well, I'd do elem_size using a comptime block, so I'd just create a length two array in there to do it with.
diltsman has joined #zig
<diltsman>
"section" changed to "linksection". I can see that this better clarifies what it references, but was there some particular case that this helps with?
<benjikun>
I know that's probably not much help, sorry
<benjikun>
haven't really used the C export functionality yet
_whitelogger has joined #zig
suirad has joined #zig
daurnimator[m] has joined #zig
suirad_ has quit [Ping timeout: 256 seconds]
benjikun has quit [Quit: Lost terminal]
tiehuis has joined #zig
<tiehuis>
daurnimator: you'll need to use an 'extern struct' the struct returned by makeThing to ensure it is c-compatible
<tiehuis>
also you'll probably need an opaqueType here on the inner node else it may be easier to simply use opaqueType for the makeThing and do a ptrCast in the c function boundary
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
m4ge123 has quit [Read error: Connection reset by peer]
davr0s has joined #zig
m4ge123 has joined #zig
shollrollah951 has joined #zig
desperek has quit [Quit: xoxo]
_whitelogger has joined #zig
<presiden>
let say I wanna write a function that takes an array and modify it
<MajorLag>
darnumator, in 1748 you ask for a way to ignore the issue. Are you aware of @alignCast? If not you might want to clarify what you're asking for.
<presiden>
^ that didn't work right, since a is const in this case
<MajorLag>
fn foo(a: *[10]u8) void { a[0] = 42; }
<MajorLag>
It works like passing structs does. If you pass it straight the compiler is free to choose if it is passed as a pointer or a copy, which means it has to be const.
<presiden>
ah, so it's pointer to an array of 10 element
<MajorLag>
yes, a pointer to an array of u8 with a comptime-known length of 10. As far as I'm aware, you can treat a *[N]T just like [N]T, so you shouldn't need to change anything else.
<presiden>
thanks MajorLag
return0e has quit [Ping timeout: 252 seconds]
return0e has joined #zig
steveno_ has joined #zig
SimonNa has joined #zig
steveno_ has quit [Ping timeout: 252 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<daurnimator>
andrewrk: re: @sizeOf(): another thought occurs. If I have a u24, I expect that it would fit in a mmap of length 3.
<andrewrk>
do you mean actual mmap? because that requires allocations of at least page size
davr0s has joined #zig
<daurnimator>
andrewrk: isn't that a linux-specific thing?
* daurnimator
not sure. just another case I was thinking about
<daurnimator>
andrewrk: either way, sizeof not being the actual size of something is... weird
<daurnimator>
I also have no idea how zig does bitfields yet
<nbjoerg>
I wouldn't put bitfields into any modern language...
<daurnimator>
I'd prefer them over composing flags for lots of system APIs
<nbjoerg>
I don't think they offer any real advantage
<nbjoerg>
but I should find the time to write the mixin proposal since that would somewhat address the c&p overhead of non-bitfield designs
errpr has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<MajorLag>
daurimator: zig uses packed structs. `const BitFields = packed struct { b0: bool, b1: bool,, b2: bool, b3: bool... b7: bool };` will be a single byte. In my experience, this is actually harder to work with that consts because you can't use bitwise operators on them.
allan0 has quit [Ping timeout: 246 seconds]
<nbjoerg>
at least from the cfe experience, they also often result in bad performance
<nbjoerg>
and large code
wootehfoot has joined #zig
Zaab1t has quit [Quit: bye bye friends]
return0e has quit []
return0e has joined #zig
benjikun has joined #zig
errpr has quit [Ping timeout: 264 seconds]
shollrollah951 has quit [Quit: Leaving]
suirad has quit [Quit: Page closed]
wootehfoot has quit [Read error: Connection reset by peer]