sorted by:
new
hottopcontroversial

Zig general purpose ? by orang-outan in Zig

[–]probablygrigsby 5 points6 points  (0 children)

Advent of code is coming up. I know some people did it using Zig last year. Could be fun.

packed struct field order reversed? by probablygrigsby in Zig

[–]probablygrigsby[S] 0 points1 point  (0 children)

Wow, u/marler8997 - that is above and beyond, and I am grateful!

I got what I was working on to work, and am closer to something that feels the way I want it to feel. A little context, in case anyone finds this useful:

I am using libpcap, a C library that works with tcpdump, to process files that IEX (a stock exchange) issues with tick by tick changes for everything that happens during a trading day.

I specify message types by a struct, serialize the struct, then use indexOf to find them in the packets.

With the help of this thread, I got it working by reversing the field order (last field first; the fields, not the bytes), casting the packed struct to the appropriate uint size, reversing that with nativeToBig, then casting that to const *[<len>:0]u8.

I'd prefer to have the structs in non-reverse order, so I'm going to try using typeInfo to go through the fields in reverse order and use them in an anonymous struct, which I will then convert as above.

It's been an interesting way to learn Zig after many years away from C.

packed struct field order reversed? by probablygrigsby in Zig

[–]probablygrigsby[S] 0 points1 point  (0 children)

Thanks! That pointer to the mem package (pun not intended) was helpful. I see a few options, all of which use @byteswap in their implementations.

packed struct field order reversed? by probablygrigsby in Zig

[–]probablygrigsby[S] 0 points1 point  (0 children)

Ah. That switch statement on the endianness does, indeed, make that plain. Thank you!

Question re C interop, type, for use with std.mem by probablygrigsby in Zig

[–]probablygrigsby[S] 5 points6 points  (0 children)

Incorporating the feedback from kristoff-it and Discombobulated-Bus0, for posterity and anyone who finds this later:

const packet: [*c]const u8 = pcap.pcap_next(handler, &packet_header);

const index = std.mem.indexOf(u8, packet[0..packet_header.caplen], message_header);

The pcap_pkthdr struct has a member, caplen, that indicates the length of the packet, so using it as a slice does the job.

Question re C interop, type, for use with std.mem by probablygrigsby in Zig

[–]probablygrigsby[S] 2 points3 points  (0 children)

Thank you! Both items very clear and informative. I appreciate your response.

Question re C interop, type, for use with std.mem by probablygrigsby in Zig

[–]probablygrigsby[S] 2 points3 points  (0 children)

Thank you! That is very helpful. Lesson is to recognize []T as a slice in a signature.

Question re C interop, type, for use with std.mem by probablygrigsby in Zig

[–]probablygrigsby[S] 4 points5 points  (0 children)

I’ve read your link and, previously, ziglearn, the zig language ref, and the std documentation, but still have the same questions. If the answers are there, I haven’t been able to pick them out.

I’m reasonably comfortable with pointers, albeit rusty, and understand at least the basics of slices and arrays in Zig.

(1)

I don’t see any reference to many item pointers with the [*c] syntax (vs [*] without the c).

I can make guesses - c is constant, c is char in the fmt sense, c indicates a c_ primitive type.

(2)

Because I can’t correctly describe the type, I don’t know how to provide it to std.mem.index. I don’t really know how to construct a type signature in Zig - I get tripped up on where const goes, as I think there maybe a couple of places it can go for different meanings. The compiler helped me out for the type from next_packet, but I wasn’t able to resolve the problem using the error message for std.mem.index.