ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<ifreund> haven't really seen anything related to that recently
jpe90 has joined #zig
radgeRayden has joined #zig
a92 has joined #zig
a_chou has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
jjsullivan__ has quit [Remote host closed the connection]
jjsullivan has joined #zig
cole-h has joined #zig
freshmaker666 has quit [Quit: ZNC 1.8.2 - https://znc.in]
haliucinas has quit [Ping timeout: 260 seconds]
haliucinas has joined #zig
a92 has quit [Quit: My presence will now cease]
ur5us has joined #zig
jpe90 has quit [Quit: WeeChat 2.9]
a_chou has quit [Quit: a_chou]
x0r19x91 has joined #zig
earnestly has quit [Ping timeout: 246 seconds]
Jeanne-Kamikaze has quit [Quit: Leaving]
xackus_ has joined #zig
xackus has quit [Ping timeout: 256 seconds]
jjsullivan has quit [Remote host closed the connection]
jjsullivan has joined #zig
freshmaker666 has joined #zig
freshmaker666 has quit [Client Quit]
freshmaker666 has joined #zig
freshmaker666 has quit [Client Quit]
freshmaker666 has joined #zig
ur5us has quit [Ping timeout: 272 seconds]
llimllib has joined #zig
x0r19x91 has quit [Quit: Connection closed for inactivity]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
a_chou has joined #zig
a_chou has quit [Quit: a_chou]
<andrewrk> leeward, yes you were working around a bug that was fixed
<andrewrk> where did you leave off with msp430? what were you trying to do and got stuck?
sord937 has joined #zig
decentpenguin has quit [Quit: ZNC crashed or something]
decentpenguin has joined #zig
jjsullivan has quit [Read error: Connection reset by peer]
jjsullivan has joined #zig
cole-h has quit [Ping timeout: 246 seconds]
dumenci has joined #zig
xackus_ has quit [Quit: Leaving]
xackus has joined #zig
xackus_ has joined #zig
xackus_ has quit [Client Quit]
xackus has quit [Client Quit]
Pistahh has joined #zig
Nilium has quit [Remote host closed the connection]
benaiah` has joined #zig
benaiah has quit [Ping timeout: 260 seconds]
benaiah` is now known as benaiah
xackus has joined #zig
ur5us has joined #zig
Astronothing has joined #zig
Astronothing has quit [Quit: WeeChat 1.9.1]
xackus has quit [Read error: Connection reset by peer]
Astronothing has joined #zig
xackus has joined #zig
alex____1 has joined #zig
Astronothing has quit [Remote host closed the connection]
alex____1 is now known as Astronothing
Astronothing has quit [Quit: WeeChat 2.8]
Astronothing has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
ur5us has quit [Ping timeout: 260 seconds]
earnestly has joined #zig
hlolli has joined #zig
rzezeski has quit [Quit: Connection closed for inactivity]
<betawaffle> oh man, the io_uring code in std is so clean!
<ifreund> yeah, it's thanks to the dude working on this neat project: https://github.com/coilhq/tigerbeetle.git
<daurnimator> is it still based on my PR?
marnix has quit [Remote host closed the connection]
<ifreund> not directly afaict but it was probably a large influence alonside liburing
marnix has joined #zig
marnix has quit [Remote host closed the connection]
marnix has joined #zig
<betawaffle> where can i find what `root.event_loop` is expected to be if it's defined? https://github.com/ziglang/zig/blob/0.7.0/lib/std/start.zig#L256
marnix has quit [Remote host closed the connection]
marnix has joined #zig
<ifreund> betawaffle: the same interface as std.event.Loop I suppose
<ifreund> at least that's what I assume looking at the definition of std.event.Loop.instance
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
rzezeski has joined #zig
lucid_0x80 has joined #zig
dumenci has quit [Ping timeout: 240 seconds]
Nilium has joined #zig
donniewest has joined #zig
waleee-cl has joined #zig
samtebbs has joined #zig
Akuli has joined #zig
hnOsmium0001 has joined #zig
cole-h has joined #zig
xackus has quit [Quit: Leaving]
cole-h has quit [Client Quit]
DrDeano has joined #zig
<DrDeano> is there a safe way from going from a element of a union back to the union itself, `@ptrCast` seems to work.
<ifreund> DrDeano: pretty sure that's UB for standard zig unions though is totally fine for extern unions
<ifreund> tldr: @fieldParentPtr() is what you want but it isn't implemented yet
<DrDeano> I did try using this, but yes, only works for structs
<DrDeano> would this work for tagged unions
<ifreund> with that proposoal implemented, yes. Currently your only option is to @ptrCast() which may or may not work
<ifreund> though I guess we could look at how the compiler implements them
<DrDeano> thanks ifreund
<DrDeano> i have found @ptrCast does work for now
<ifreund> yeah so that's technically UB but I don't expect that to actually break :D
<fengb> It can easily break if the hidden tag location is moved
cole-h has joined #zig
<ifreund> hmm, right llvm could decide to do that for whatever reason
xackus has joined #zig
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
<fengb> One of those cases where a non-safe mode would probably work more consistently because it doesn't have a secret tag >_>
<marler8997> DrDeano I'm curious what your use case is for using @fieldParentPtr on a tagged union, do you have code to share?
g-w1 has quit [Ping timeout: 265 seconds]
g_w1 has quit [Ping timeout: 256 seconds]
g_w1 has joined #zig
<DrDeano> it is for the VFS in Pluto: https://github.com/ZystemOS/pluto/pull/271. This PR has and example of this
g-w1 has joined #zig
<DrDeano> marler8997 it is for going from a FileNode/DirNode to Node
samtebbs has quit [Remote host closed the connection]
radgeRayden has quit [Remote host closed the connection]
wootehfoot has joined #zig
aterius has left #zig ["User left"]
luismanfroni has joined #zig
xackus has quit [Ping timeout: 272 seconds]
llimllib has quit [Quit: Connection closed for inactivity]
Astronothing has quit [Quit: WeeChat 2.8]
greisean has joined #zig
greisean has left #zig ["Good Bye"]
layneson has joined #zig
luismanfroni has quit [Remote host closed the connection]
luismanfroni has joined #zig
DrDeano has quit [Ping timeout: 245 seconds]
_whitelogger has joined #zig
lucid_0x80 has quit [Ping timeout: 265 seconds]
luismanfroni has quit [Remote host closed the connection]
luismanfroni has joined #zig
siulManfroni has joined #zig
luismanfroni has quit [Remote host closed the connection]
ur5us has joined #zig
wootehfoot has quit [Quit: Leaving]
swanprince has joined #zig
<swanprince> Hey, I watched andrewrk's video on creating a chat server. I'm not familiar with how much progress has been made in that area, but how suitable is Zig for building a fully-fledged chat server, something like a Matrix homeserver?
<andrewrk> async I/O and std lib networking are still experimental
<andrewrk> if you want to participate in the development of these features, then it would be a good time to get involved. if you are more focused on the application being robust and stable, you should wait a couple release cycles
layneson has quit [Ping timeout: 240 seconds]
zippoh has joined #zig
<ifreund> as the author of a relatively large project in zig, I'd say go for it if you want to. You will eventually hit zig bugs but for me zig's features have made it worth it over C despite that
<ifreund> if you want the everything "just works" experience though it'd be best to wait a bit longer
<swanprince> Understood. I'd like to build something like that as a learning experience. Matrix seems like a good idea, but I'm wondering how a non-Python homeserver would perform.
<oats> swanprince, iirc a golang homeserver is under development, and is intended to eventually replace synapse
<oats> not trying to discourage you from zig or anything :P
<swanprince> Yeah, I'm aware of dendrite
<oats> I also would be excited to run not-synapse :P
<ifreund> matrix is very complex
seadragon-droid has joined #zig
<swanprince> Yeah, that's true, but it supports a ton of features
<ifreund> more features isn't always a good thing really
<ifreund> see: C++ vs C/Zig
<swanprince> Also true
<seadragon-droid> Does anyone know where I can find details about the use-after-free detection in the general purpose allocator? I tried to look through the source in the stdlib but couldn't find any clues
<swanprince> Since the homeserver has an open specification, you could choose a subset of features and implement those
<oats> swanprince: couldn't that risk incompatibilities and issues when interacting with other servers?
<andrewrk> seadragon-droid, the source is only 655 lines of code
<andrewrk> 555 if you don't count docs
<andrewrk> in summary: std.heap.page_allocator uses a trick where it uses a global, atomic, monotonically increasing address hint rage for requesting pages from the OS. this means that we go through the entire address space before re-using addresses. so if a UAF happens in such a page it will cause a segfault rather than undefined behavior
CodeSpelunker has joined #zig
<andrewrk> GPA backed by page allocator uses this trick for large allocations, and for small allocations, will not re-use slots, and will explicitly detect UAF and print diagnostics
<swanprince> oats: I would guess there are ways to account for that. You don't need a fully-spec'd server to interact. There are plenty of experimental servers which people are dogfooding right now, and they can interact with Synapse servers. Correct me if I'm wrong, but Synapse doesn't completely implement the spec.
wootehfoot has joined #zig
CodeSpelunker2 has joined #zig
CodeSpelunker has quit [Read error: Connection reset by peer]
<seadragon-droid> andrewrk: Thanks for details. I agree the implementation is straightforward to read, and I'm doing my best to grok the details
marnix has quit [Ping timeout: 240 seconds]
<andrewrk> I'm happy to answer questions
<seadragon-droid> Page fault due to monotonically increasing pages makes sense for the large allocations (although I imagine freestanding support for that fault is fairly varied?) What's the mechanism for UAF for small allocations?
<andrewrk> in case you missed it, there's a brief docs section there under a heading titled "Basic Design". UAF detection is done the same way as leak detection - there is a bit for every slot to track whether it is used, and slots are never re-used
<andrewrk> hm a better name would be Design Overview rather than Basic Design
<hlolli> Over the last week, I've encountered this error quite often "Unreachable at /build/source/src/stage1/analyze.cpp:890 in get_slice_type. This is a bug in the Zig compiler.". Not really a question, but thought I'd mention it 4wiw.
<andrewrk> the next step towards getting it fixed is a minimal test case to reproduce the issue
<andrewrk> before you do any work to come up with such a case, search around the issues - it's possible someone else already did the work
<hlolli> andrewrk, ok will do! I wasn't sure if this is well known or not :)
<hlolli> seems to be not reported yet, so I'll try to make a reproduceable case.
wootehfoot has quit [Quit: Leaving]
swanprince has quit []
<ifreund> looks like 0.7.1 is blocked on all windows issues aside from the one deadlock now :D
nycex has quit [Ping timeout: 240 seconds]
<andrewrk> hopefully #7309 will make it easier to debug windows issues :)
<seadragon-droid> andrewrk: Yes I saw that part thankfully - I might be missing something but my understanding is that the allocator knows the slot is freed but I don't see how it would detect a dereference to the freed memory. i.e. the dereference seems "safe" since the slot is not reused but it doesn't seem to be "detected"
<andrewrk> seadragon-droid, ahh I see. right, UAF is not detected in this case, it is merely safe. sorry, I got mixed up with Double Free which is detected
<g-w1> is everything else ready for when the issues get solved 0.7.1 will release, or are there more TODOs besides the issues?
<andrewrk> seadragon-droid, there is one more factor here however, which is that we set the memory to undefined upon free. so a UAF read will likely be detected, especially once we have detection of branch-on-undefined
<andrewrk> g-w1, I do have some release notes to type up
CodeSpelunker2 has quit [Quit: CodeSpelunker2]
<andrewrk> the issues is the main thing though
CodeSpelunker has joined #zig
<seadragon-droid> andrewrk: Ah! I was wondering if undefined detection might become part of it. I'll keep my eyes on that one then
nycex has joined #zig
<nore> so I got curious and I read the code of the GPA, it seems to me that in this line https://github.com/ziglang/zig/blob/master/lib/std/heap/general_purpose_allocator.zig#L532 self.total_requested_bytes should be reset to prev_requested_bytes if the memory limit is enabled, but it is not (or I might have missed something)
<seadragon-droid> Glad to hear it too, because I wasn't wholly convinced it was a good idea to have silent safety for debug/releasesafe that isn't shared by releasefast (not desirable to have certain memory bugs only in releasefast mode)
<nore> (not sure if I should ping someone)
llimllib has joined #zig
CodeSpelunker has quit [Quit: CodeSpelunker]
CodeSpelunker has joined #zig
<nore> andrewrk: do you think it's normal, or is it a bug? (I'm asking you since you seem to be the author of the code)
siraben has quit [*.net *.split]
ky0ko1 has quit [*.net *.split]
travv0 has quit [*.net *.split]
zippoh has quit [Remote host closed the connection]
seadragon-droid has quit [Ping timeout: 256 seconds]
Akuli has quit [Quit: Leaving]
sord937 has quit [Quit: sord937]
<andrewrk> I'm working on something else at the moment, will take a look in a little bit
<andrewrk> thanks for sponsoring zig, hlolli :)
<nore> thanks! (I was just making sure that it didn't go unnoticed, I hope it's not that I misunderstood the code)
<ifreund> nore: the line you linked doesn't seem to be the one you are talking about...
<ifreund> or maybe I misunderstood
zippoh has joined #zig
<nore> ifreund: what I meant is that at this point, self.total_requested_bytes should be reset, but we modified it line 485
<nore> (and the reset code does not run, since it is inside an errdefer=
<nore> *)
<ifreund> ah I see, the errdefer wouldn't trigger as we return 0 not an erro
<nore> yes
CodeSpelunker has quit [Quit: CodeSpelunker]
<hlolli> andrewrk no problem, I wish this project all the best, I hope it may bring me powers :)
<ifreund> nore: yeah afaict you're right, you should totally open a PR :D
<leeward> That thing about errors that are silently corrected in safe modes is definitely right. Those will lead to bad bugs.
<leeward> If it's not handled in release fast, it should crash in debug.
CodeSpelunker has joined #zig
<leeward> Ooh, that's fun. I got an error in stage2: "TODO implement mappings for c_longdouble"
travv0 has joined #zig
ky0ko1 has joined #zig
siraben has joined #zig
<ifreund> leeward: it's not that the error is silently corrected, it's noisy about the double free, it's that the codepath makes the reporteded total requested bytes incorrect
<leeward> ifreund: Ah, ok. Still a bug, but not quite as awful.
<leeward> Still pretty bad sounding.
<ifreund> not super terrible, it doesn't affect the behavior just the reporting
<ifreund> well spotted though by nore :)
siulManfroni has quit [Remote host closed the connection]
<nore> thanks :) opened #7332 with a fix
<leeward> Well, this is an easy thing to fix. I just have to implement the mapping for c_longdouble. Not entirely sure why it needs it, since I'm not using any floating point code, but...it's stage1 so I'm not going to worry about it.
<leeward> Hah, and it works!
<ifreund> nice
CodeSpelunker has quit [Quit: CodeSpelunker]
<betawaffle> Is @setCold(false) useful?
<leeward> I like trivial-to-review PRs.
<ifreund> betawaffle: maybe if inside a branch where @setCold(true) has been previously used?
<leeward> betawaffle: That there is a good question.
<leeward> The documentation suggests it applies to whole functions.
<fengb> setCold is currently function level. There's an issue to make it block based
<leeward> Would it make sense even if block based though? It's not like a nested block could be hot while its parent is cold.
<betawaffle> As long as that’s planned, I’m ok. I was wondering why it accepted an argument.
<andrewrk> betawaffle, I believe there is a proposal to replace it with @cold() and have it apply to code paths rather than functions
<justin_smith> similar to c if(unlikely(expr)) ... ?
<fengb> leeward: that's why it's called setCold, not setHot 🤓
<leeward> Hah, I just noticed there isn't a predict_false type feature. That makes sense.
* ifreund thought it already did apply to code paths...
<leeward> The docs say "Tells the optimizer that a function is rarely called."
<andrewrk> a useage pattern with @setCold would be `const some_value = @import("build_options").foo;` @setCold(some_value)
<dominikh> has marking things cold actually proven to make a meaningful difference?
<betawaffle> Fair enough
<ifreund> could that not just as easily be `if (some_value) @setCold()`?
<betawaffle> Not if it applies to code paths.
<ifreund> true
<ifreund> though the argument could be made that comptime branches shouldn't count
<betawaffle> Yep!
donniewest has quit [Quit: WeeChat 3.0]
<andrewrk> logically, `if (true) @cold()` would apply to the outer branch as well
<andrewrk> similar to how `if (true) unreachable;` can be simplified to `unreachable`
<dominikh> if you argue based on executed control flow, not syntax, yeah. which I suppose makes sense if you treat @cold as a function call
<dominikh> though people might expect it to be block scoped
<dominikh> would you expect `if (sometimes_true) @cold()` to apply to code that follows the `if`, sometimes? that doesn't seem easy to reason about by reading the code
<andrewrk> what I mean is even if it is block scoped, and it is `if (true) @cold()` then you can conclude that the outer block is cold as well, through logical deduction
<dominikh> yes, but I am questioning whether the compiler should make that conclusion or not.
<dominikh> because if it's block scoped, it is not obvious that the deduction matches the programmer's intent
<andrewrk> I'm pretty sure it mathematically, logically does
<dominikh> in the control flow, machine executing code sense, yes. not in the human, writing block-based code in an editor sense
<dominikh> `if (true) const x = 1` does not add x to the outer scope, even though logically, x exists on all paths.
<earnestly> This is more of a concern where C could end up eschewing NULL checks
<leeward> Why the heck is this compiler generating a JMP instruction with an offset of 0? This is weird sauce.
<leeward> Oh well, moving on...
rslabbert has joined #zig
<fengb> It's an extra strong noop
<leeward> It's a little weird the ISA even allows it. It's a 2-cycle noop.
<leeward> All this talk about orthogonality of the instruction set...
<fengb> That may take longer depending on how the branch is interpreted :)
<leeward> msp430 all jxx instructions are 2 cycles, according to the user guide.
<leeward> "independent of a successfull[sic] Jump or not"
<fengb> Oh... jumps don’t take extra time?
<fengb> No pipeline or something?
<leeward> Well, jumps take 2 cycles, which is longer than most instructions, but no pipelines.
<leeward> That includes the branches.