darithorn__ has quit [Read error: Connection reset by peer]
darithorn__ has joined #zig
fsateler has quit [Read error: Connection reset by peer]
fsateler has joined #zig
darithorn_ has joined #zig
darithorn_ has quit [Read error: Connection reset by peer]
darithorn_ has joined #zig
darithorn__ has quit [Read error: Connection reset by peer]
<daurnimator>
andrewrk: allocating stack on demand -> instead the zig way is a @ensureStack() builtin?
<daurnimator>
andrewrk: note that allocating stack of demand is the *norm* -> if you want to be able to write libraries in zig to use with C (which to me is one of the main benefits of zig), then you need to deal with it...
daurnimator has quit [Ping timeout: 240 seconds]
<scientes>
daur.....gone
daurnimator has joined #zig
darithorn__ has joined #zig
darithorn_ has quit [Ping timeout: 245 seconds]
<scientes>
wow, I was writing a exit_group() patch at the same time......
<scientes>
and i never saw the bug
<daurnimator>
scientes: sometimes you've got to be quick around here ;)
<mikdusan>
👍 that patch looks strangely byte-for-byte identical to my push
Akuli has joined #zig
Ichorio has joined #zig
<andrewrk>
the extern "foo" feature is useful on Windows to generate dependencies on kernel32.dll, ntdll.dll, etc
<mikdusan>
so it’s a mechanism to indicate to linker which libs symbs are actually used instead of blanket lib linking. there’s no equiv in C, correct?
vyzkoh__ has joined #zig
vyzkoh_ has joined #zig
vyzkoh__ has quit [Client Quit]
vyzkoh_ has quit [Read error: Connection reset by peer]
noonien has quit [Quit: Connection closed for inactivity]
<andrewrk>
correct
Hejsil has joined #zig
<Hejsil>
andrewrk, currently working on https://github.com/ziglang/zig/issues/863 and hit a problem I'm not sure exactly how to get past. We have this `([*]align(alignment) T)(undefined)[0..0]` in mem.zig at it crashed my current implementation, because *[0]T is a 0 bit type, so an assert ensures that it has alignment 0
<andrewrk>
hi Hejsil, I think that assert might not be necessary. where is the assert?
<andrewrk>
oh, is this a new assert you added?
<Hejsil>
analyze.cpp:527
<Hejsil>
No
<andrewrk>
ok, in this context, byte_alignment == 0 means that the pointer type has ABI alignment and therefore an explicit align(x) is not required in the pointer type
<andrewrk>
thinking out loud here, alignment for a zero bit type doesn't make sense because there is no address, so alignment is not relevant in any way
<Hejsil>
Makes sense
<Hejsil>
Btw, the `([*]align(alignment) T)(undefined)[0..0]` is on mem.zig:101
<Hejsil>
For more context
<Hejsil>
In alignedAlloc
<andrewrk>
let me see if I can trigger that assert in master branch
<Hejsil>
Well, it is my changes that have caused this. It happens because with the new changes, slicing [0..0] gives you *[0]T but this ptr has an explicit alignment which kinda breaks this "cast"
<andrewrk>
Hejsil, here's a clue: in ir_analyze_instruction_ptr_type there is logic that says if (!type_has_bits(child_type)) align_bytes = 0
<andrewrk>
so that's why `var x: *align(4) void = {}` doesn't crash in master branch
<Hejsil>
Aah, I see
<andrewrk>
I think it does make sense for a zero bit type to "destroy" alignment information in the pointer, because there is no address
<andrewrk>
and you won't be able to @ptrCast back to a non zero bit type
<andrewrk>
however I think that a 0 len slice is allowed to have a pointer with aligned address as long as the element type has bits
<andrewrk>
I also think this should be allowed: *align(4) [0]u8
<andrewrk>
that could be, for example, the "end" pointer address of a block of memory
<andrewrk>
Hejsil, does that help?
<Hejsil>
I'll try work from here :)
<andrewrk>
hmm. the *align(4) [0]u8 thing contradicts master branch
<andrewrk>
I think that requires more thought
<Hejsil>
Actually, shouldn't we keep the alignment information for implicit cast?
<Hejsil>
like *align(4) const [0]T -> []align(4) const []T
<andrewrk>
the thing that makes sense to me is not keeping alignment information if there is no address
<andrewrk>
e.g. if @ptrToInt would give "error: pointer to size 0 type has no address" then alignment shouldn't be possible
<andrewrk>
if we keep alignment information, we better keep the pointer address too
<Hejsil>
Hmmmm
<Hejsil>
Let me see when I hit a roadblock next, then I'll think about it some more. I'll try to throw away alignment for now
<andrewrk>
ok
<andrewrk>
yes this may be an orthogonal problem you have run into, that doesn't have to be solved with your work on 863
<Hejsil>
It might have to, as alignedAlloc relies on this cast :)
<andrewrk>
for the new_n == 0 case?
<Hejsil>
Alright, I should stop talking until I actually hit the problem I'm thinking of, lol
<Hejsil>
More coding less talking!
<andrewrk>
haha
<Hejsil>
My terminal exploded with compiler errors, but not the errors I expected
<Hejsil>
zig compiler errors, not cpp compiler erros
<Hejsil>
The type system should alway use the instructions type and not the ConstExprValue's type for typechecking yes?
<andrewrk>
the ConstExprValue type tells how the data is stored in the ConstExprValue data structure. the instruction's type is the user-visible type according to zig semantics
<andrewrk>
I think that's a "yes"
<Hejsil>
Alright, then I think I've hit a but along the way. Let me make sure I'm correct here
wilsonk has quit [Ping timeout: 250 seconds]
wilsonk has joined #zig
wilsonk has quit [Ping timeout: 246 seconds]
dd10 has joined #zig
wootehfoot has joined #zig
<dd10>
Hello everyone, I'm just discovering Zig-lang, am I correct if I say that “zig-general-purpose-allocator” (https://github.com/andrewrk/zig-general-purpose-allocator) is a way guarentee safety at compile time for the majority of possible failures listed at "memory leak" section in this page: https://en.wikipedia.org/wiki/Memory_safety ? According to some searches on the web, Zig is not considered like a "safe" language (I mean as Rust prom
<dd10>
But the on-going work let me think that Zig would like to improve this?
<andrewrk>
dd10, not at compile time
<andrewrk>
zig is not a safe language
<andrewrk>
and it's not planned to ever be
<andrewrk>
your first comment got cut off at "Rust prom-"
<dd10>
ok, it's clear now =)
<dd10>
the comment was: According to some searches on the web, Zig is not considered like a "safe" language (I mean as Rust promises).
<dd10>
thanks for responses
<andrewrk>
dd10, no problem. zig tries to make it more difficult to cause undefined behavior than other unsafe languages, but it cannot be guaranteed at compile time, and some kinds of undefined behavior cannot be caught at runtime either
<mikdusan>
i gotta say discovering the pleasant benefits for something as rudimentary as slices combined with “strings” that are not null terminated.
<mikdusan>
the othe day i wrote a fn to split a string on EOF boundries (lines) and was dreading it. but it turned out to be real easy thanks to slices, and didn’t need to alloc memory for the lines either because no null termination.
<andrewrk>
mikdusan, you can use std.mem.tokenize or std.mem.separate for that
<mikdusan>
even easier
<andrewrk>
var it = std.mem.tokenize(buffer, "\n\r"); while (it.next()) |line| doSomething(line);
<andrewrk>
Akuli, you may find std.Buffer helpful
<Akuli>
i think my main question was whether i really need an allocation each time, because this function is called very often
<andrewrk>
in this case why not make mvaddstr take a [*]const u8?
<Akuli>
what's that :D
<Akuli>
let me look it up from the reference
<andrewrk>
it's the type of cstr.ptr, the type that you're creating to pass to mvwaddstr
<Akuli>
how would i call the function then? would i need to use c strings everywhere in the rest of the program?
<Akuli>
hmm you know what i should do
<Akuli>
i should use mvwaddnstr instead, it takes the length of the string as an argument
<andrewrk>
you're calling a C function that expects a C string, and you don't want to convert from slices, so that would make sense wouldn't it?
<andrewrk>
now that's a much better solution
<andrewrk>
after https://github.com/ziglang/zig/issues/265 the type of string literals will be *[N]null const u8. this will implicitly cast to [*]null const u8, which will help a bit because you'll be able to pass zig string literals to functions which expect C strings
<andrewrk>
oops. *const [N]null u8
dd10 has quit [Ping timeout: 256 seconds]
Zaabtop has joined #zig
Zaab1t has quit [Ping timeout: 245 seconds]
Zaabtop is now known as Zaab1t
Zaab1t has quit [Quit: bye bye friends]
Hejsil has quit [Quit: Page closed]
<mikdusan>
andrewrk: apologies at this basic question; but why is `@typeOf(“hello”)` → `[5]u8` and not `[5]const u8` ?
<andrewrk>
`[5]const u8` isn't a type
<andrewrk>
`const` is a pointer attribute
<andrewrk>
and the array type isn't a pointer
<mikdusan>
ok so whenever i see const it’s only about pointer.
<andrewrk>
right. even on variables - you can think of `const` as meaning that if you take the address you'll get a const pointer
<andrewrk>
after https://github.com/ziglang/zig/issues/265 is done, string literals will be pointers, not arrays. and so they will have `const` in them like you expected
<mikdusan>
yes 265 was what made me ask this. my head is spinning a bit.
<mikdusan>
re: literals will be points; so “hello” would have typeof `[]const u8` without the need for slicing syntax?
<andrewrk>
`@typeOf("hello")` will be `*const [5]null u8` which implicitly casts to `[]const u8`
<andrewrk>
status quo string literals cast to `[]const u8` without the need for slicing syntax. but it's a bit of a hack. we'll be removing a possible footgun by changing it
<mikdusan>
ah. i see *const.
scientes has joined #zig
<andrewrk>
reading `*const [5]null u8` from left to right: "pointer to one 5-element array, which has an extra 0 element not counted in the length, of u8s"
jjido_ has joined #zig
<mikdusan>
i think it’s a good decision to not count nullz.
<andrewrk>
oops, forgot to add "immutable" in there
<andrewrk>
reading `[]const u8`: from left to right: "pointer to a number of elements known at runtime of immutable u8s"
<mikdusan>
not entirely clear from 265, if c-literals are going away, what is syntax to specify a literal string with nullz ?
<andrewrk>
all string literals will have a null byte after them
<andrewrk>
that's why `@typeOf("hello")` will be `*const [5]null u8` - it has the `null` in there
* mikdusan
i think that’s a reasonable tradeoff to avoid another syntax. but if u didn’t want to nullz pure zig literals, then something simple like suffix could work?
<mikdusan>
like “hello” vs. “hello”z
<andrewrk>
so 265 lets us delete syntax from the language. string literals will cast to `[]const u8` (zig-preferred byte slice) as well as `[*]null const u8` (C strings)
<andrewrk>
why would you want to do that? to shave off a few bytes from your program size?
<mikdusan>
i guess that’s all it saves
<andrewrk>
if that's an issue, zig can probably detect when a string literal is never casted to `[*]null const u8` and omit the null byte
<andrewrk>
I don't think anyone will find that necessary. C programs already have the null byte for every string literal, and nobody cares about that
<mikdusan>
and the guarantee is only that there is nullz, and there is NO guarantee about bytes before nullz; ie: if someone is setting other spots to zero
<andrewrk>
correct
<tgschultz>
I remember raising the same objection, but withdrew it after I realized that you can use a comptime function call to turn any `*const [N]null u8` into a `[N]u8` if that's really what you want.
<mikdusan>
save-a-nullz-byte-optimizer-pass
<scientes>
why pub const abi = Abi.gnu; and pub const link_libc = false; ?
dd10 has joined #zig
<scientes>
why isn't that abi=Abi.none ?
Akuli has quit [Quit: Leaving]
<andrewrk>
scientes, it specifies the ABI of extern functions and structs
Ichorio has quit [Ping timeout: 255 seconds]
alot has quit [Quit: WeeChat 2.4]
<andrewrk>
scientes, I don't think you need to do that pthread_self stuff. there's a simple way to make this work and there is an established pattern: if (builtin.link_libc) then use pthread mutexes rather than zig's own implementation
<andrewrk>
see for example the implementation of std.os.abort, std.os.exit, std.os.spawnThread
<scientes>
I need it to do robust mutexes that can be shared between 32-bit and 64-bit
<scientes>
but I will have to investigate if it can co-exist with musl or glibc pthreads
dd10 has quit [Quit: Page closed]
<andrewrk>
ok. you might consider opening an issue to discuss your use case if you want this merged into the standard library, because it sounds kinda weird
<scientes>
it won't work with pthread_mutex_t, but I would like the same thread to be able to run musl or glibc thread code and pthread locks, and also zig code and locks
<scientes>
however the offset that glibc uses that we have to match to make THAT work, is 24 bytes, which is also a little bigger than I would like the SharedMutex struct to be
<andrewrk>
right so I'm not familiar with this use case, and I haven't read that URL yet, and I consider this to be a different issue than #1455. so I'm just giving you a heads up, this isn't an obvious "cool, done, merged" situation. I'll need to understand it first
<scientes>
so maybe it would be forbidden to use zig threading and pthread threading from the same thread
<scientes>
yes, I C. here is the use case: sometimes you need locking between a client and server, and that server might run 64-bit while the client is 32-bits
<andrewrk>
I'll read the logs - gotta run
<wrl>
scientes: do you just need to do this on linux?
<scientes>
I don't know anything about locking on other platforms
<wrl>
use eventfd if you can
<wrl>
like if you can build the primitive you need with it
<scientes>
A use code would be pulseaudio
<scientes>
which currently is slow from 32-bit clients on a 64-bit system (I don't have benchmarks), because of the lack of this