Live data from Hacker News

Packed structs in Zig make bit/flag sets trivial

devlog.hexops.com

131–140 of 147 posts

Re: Packed structs in Zig make bit/flag sets trivial

#131
post #17
post #5

Earlier quoted context omitted.

It also specified the layout (little endian) and disallowed reordering / padding / etc.

How bitfields are allocated within a byte is related, but independent from endianness. endianness: how an array of bytes is interpreted as an integer/how an integer is layed out in memory as an array of bytes. bitfield allocations: how subsequent bitfields are allocated within an integer, typically starting from least significant bit to most significant, or the other way around.

Fair, and a good point.

In this particular case, the two are related, because the LSBit-first bitfield allocations can spill over between bytes, giving LSByte-first endianness as well.

Re: Packed structs in Zig make bit/flag sets trivial

#132
post #9

Earlier quoted context omitted.

Indeed, you would need to check that the mask ends up being exactly alpha and blue, otherwise it's just an automatic boolean conversion from integer to boolean, which many languages are doing away with due to all the bugs it produces.

Yeah, you cant do that in Go, even explicitly: // cannot convert i (variable of type int) to type bool bool(i) youd need to use a function: func to_bool(i int) bool { return i != 0 }

Seems a bit mean-spirited to provide casts but not that one.

Re: Packed structs in Zig make bit/flag sets trivial

#133

Earlier quoted context omitted.

Yeah, you cant do that in Go, even explicitly: // cannot convert i (variable of type int) to type bool bool(i) youd need to use a function: func to_bool(i int) bool { return i != 0 }

Seems a bit mean-spirited to provide casts but not that one.

not really. Go has no concept of truthy:

https://developer.mozilla.org/docs/Glossary/Truthy

and I fully support that decision. If you want to use a boolean, you need to be explicit about it.

Re: Packed structs in Zig make bit/flag sets trivial

#134
post #59

Earlier quoted context omitted.

Bit fields in C are notoriously non-portable (exact physical layout depends on the compiler). Is Zig any better (apart from the fact that there is only one Zig compiler for now)?

Notoriously? I can't name any architecture/platform/compiler where bits aren't allocated consecutively in order of definition, without holes, in the same direction as system endianness...

Try this in clang and gcc:

    #pragma pack(1)
    struct S {
        char c:1;
        char d:1 __attribute__((aligned(2)));
        char e:1;
    };
    _Static_assert(sizeof(struct S) == 1, "wrong size");

Re: Packed structs in Zig make bit/flag sets trivial

#135

Earlier quoted context omitted.

Seems a bit mean-spirited to provide casts but not that one.

not really. Go has no concept of truthy: https://developer.mozilla.org/docs/Glossary/Truthy and I fully support that decision. If you want to use a boolean, you need to be explicit about it.

A statically typed language shouldn't indulge in truthiness, no. But a cast is isn't truthiness, it's truth: the meaning of "make this int impenetrable to all but truth and falsehood" is in practice well defined, there's nothing implicit happening here.

The compiler isn't going to make that function, it's going to optimize back to a cast to boolean. Why make the poor shmoe user type it out?

Re: Packed structs in Zig make bit/flag sets trivial

#136
post #93

Earlier quoted context omitted.

If that’s user error, then there’s nothing wrong with C, C++, Java, JavaScript and myriad other languages. Then we don’t need any new ones on the basis of readability, elegance, expressiveness and myriad other subjective properties. Yet many discuss these aspects primarily.

I believe parent was sarcastic and agrees with you.

I have to go to chandler’s sarcasm class. Can I BE any more obvious?

Re: Packed structs in Zig make bit/flag sets trivial

#137

Earlier quoted context omitted.

not really. Go has no concept of truthy: https://developer.mozilla.org/docs/Glossary/Truthy and I fully support that decision. If you want to use a boolean, you need to be explicit about it.

A statically typed language shouldn't indulge in truthiness, no. But a cast is isn't truthiness, it's truth: the meaning of "make this int impenetrable to all but truth and falsehood" is in practice well defined, there's nothing implicit happening here. The compiler isn't going to make that function, it's going to optimize back to a cast to boolean. Why make the poor shmoe user type it out?

Cast int8 to int16 isn't the same thing as int to boolean. In the first case, you get the same number (ignoring wrapping issues). In the second case, you're asking the compiler to make an arbitrary decision about what numbers go to what booleans.

Re: Packed structs in Zig make bit/flag sets trivial

#138

Earlier quoted context omitted.

A statically typed language shouldn't indulge in truthiness, no. But a cast is isn't truthiness, it's truth: the meaning of "make this int impenetrable to all but truth and falsehood" is in practice well defined, there's nothing implicit happening here. The compiler isn't going to make that function, it's going to optimize back to a cast to boolean. Why make the poor shmoe user type it out?

Cast int8 to int16 isn't the same thing as int to boolean. In the first case, you get the same number (ignoring wrapping issues). In the second case, you're asking the compiler to make an arbitrary decision about what numbers go to what booleans.

There is nothing arbitrary whatsoever about the conversion of any string of bits to a boolean, it is false iff none of the bits are 1.

If you want to call it arbitrary, it's been arbitrated decades ago, but Boolean logic is much older than computers and works as it does for a reason. I suspect you know that.

Re: Packed structs in Zig make bit/flag sets trivial

#139

Earlier quoted context omitted.

Cast int8 to int16 isn't the same thing as int to boolean. In the first case, you get the same number (ignoring wrapping issues). In the second case, you're asking the compiler to make an arbitrary decision about what numbers go to what booleans.

There is nothing arbitrary whatsoever about the conversion of any string of bits to a boolean, it is false iff none of the bits are 1. If you want to call it arbitrary, it's been arbitrated decades ago, but Boolean logic is much older than computers and works as it does for a reason. I suspect you know that.

the number 9, is not the same thing as "true". some people may want it to be, it might be convenient for some people if a compiler treats them as the same thing, but they aren't. In my opinion, its an anti-pattern to have the compiler make these type of decisions. Instead of writing and reading code that is explicit, you're writing an abbreviated version of what you want, and assuming that the compiler will know what you mean.

Re: Packed structs in Zig make bit/flag sets trivial

#140

> This all works, people have been doing it for years in C, C++, Java, Rust, and more. In Zig, we can do better. We can also do better in those other languages, too. For example, in Rust, I can use a crate like `bitfield` which gives me a macro with which I can write bitfield! { pub struct Color(u32); red, set_red: 0; green, set_green: 1; blue, set_blue: 2; alpha, set_alpha: 3; } Don't get me wrong: it's cool that fu…

I’ve got to admit having used packed structs in rust quite a bit i’m also a little confused about what Zig is improving on.

Many years ago I wrote a rust program to decode some game save data and it looks like what you’d expect.

https://github.com/aconbere/monster-hunter/blob/master/src/o...

Post reply on HN