14:28 <forgot-password> Is it possible to have @compileLog not abort compilation? Or is std.debug.warn intended to take that place once https://github.com/ziglang/zig/313 is fixed?

18:31 <forgot-password> exit

18:31 <forgot-password> Oops, sorry :)

19:20 <vegecode> hey all, I have a struct and I want to use std.mem.compare to compare two of them. How can I turn it into a slice? I tried (&my_struct)[0..] and a few other tries.

19:22 <MajorLag> std.mem.asBytes(&my_struct) will return a pointer to a byte array

19:22 <vegecode> Thanks

19:23 <vegecode> Talk about unwieldy though

19:24 <MajorLag> it's explicit. comparing structs this way isn't the best anyway, because padding bytes can differ between otherwise identical structs. That's why there's std.mem.eql

19:24 <vegecode> That should be in the docs maybe. How the heck could I have found that on my own in a reasonable amount of time?

19:25 <MajorLag> the std library isn't documented yet, in part because it's big and changes frequently. It's on the todo list.

19:28 <MajorLag> sorry, I meant std.meta.eql, not mem.eql

19:28 <MajorLag> completely different

19:29 <MajorLag> meta.eql will use typeInfo to compare every field, so the padding bytesare ignored.

19:30 <MajorLag> that call would just be `std.meta.eql(my_struct_a, my_struct_b);`

19:31 <vegecode> Thanks!

19:34 <redj> MajorLag: ignore this if you're busy but I'm curious... how would that happen? why would padding bytes differ between "otherwise identical structs" and is that structs with the same fields of same data type in same order? sadly I'm not familiar with all this padding memory stuff... :P

19:35 <vegecode> I would think that a single compilation unit would have all structs of the same type have the same padding. Is this not true?

19:37 <MajorLag> They have the same number of bytes for padding, but because those bytes don't belong to a field they're left undefined, so they could be whatever was in that memory before you created the struct. If you then compare the structs byte-by-byte, you're comparing the contiguous memory the structs occupy, which includes the undefined bytes.

19:39 <MajorLag> does that make sense?

19:41 <vegecode> It does, I'm surprised the compiler doesn't zero initialize those unnamed fields. I keep getting stuck in a C way of thinking. I keep making the "&&" comparison mistake.

19:42 <MajorLag> zero initialization has a cost.

19:42 <redj> ah, undefined paddyng bytes, makes sense

19:43 <MajorLag> and also is probably optimized out all the time whether you want it to be or not

19:43 <redj> I thought you meant the padding wasn't in the same location or something

19:44 <MajorLag> Well actually,a small modification to std.meta.eql would let you compare structs that have the same field names, but in different locations.

19:44 <redj> yay for optimility! ;)

19:44 <redj> optimality* or being optimal

19:45 <MajorLag> Right now meta.eql enforces that you pass it the same type for each parameter, but it doesn't have to.

19:47 <redj> I guess optimiality is a thing in linguistics... I wonder if it can apply to programming languages... perhaps not.

19:48 <MajorLag> In fact, I'm toying with a similar idea in my rewrite of my image libraries. you can pass the RGB pixel format you want as a struct (packed struct{r: u5, g: u6, b: u5}, for instance.) and the code can automatically convert the source data before dumping it into your buffer.

19:50 <vegecode> It's guaranteed by the c standard for non initialized fields. If it is optimized out then the compiler is not standards compliant I believe.

19:51 <vegecode> But you're right

19:51 <vegecode> why not just use the abilities of the more advanced compiler?

19:52 <vegecode> Thanks again for taking the time to respond.

19:54 <MajorLag> I don't know precisely what zig's defined behavior for structpadding byte initialization is. It probably does set it to 0 in at least debug and safe modes.

20:09 <vegecode> I am also testing some code for putting a terminal into raw mode so that I can do a readline type of clone. If a test fails, the defer statement I have that is supposed to restore the terminal to canonical mode doesn't run. Can I override the panic function for test mode only?

20:20 <MajorLag> I think what you'd do is override the panic and check the current build mode using something like `if(builtin.is_test) myPanic() else defaultPanic()`

20:20 <MajorLag> but someone who actually has overridden panic before would be a better source of information on that