Linux

9230 readers

1245 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago

MODERATORS

Ategon@programming.dev

anzo@programming.dev

dwraf_of_ignorance@programming.dev

148

Linus Torvalds Rejects RISC-V Changes For Linux 6.17: "Garbage" (www.phoronix.com)

submitted 3 weeks ago by Sunshine@piefed.ca to c/linux@programming.dev

44 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] FizzyOrange@programming.dev 20 points 3 weeks ago (1 children)

Sort of. He's definitely right that make_u32_from_two_u16 is a terrible function name that obscures the meaning but I don't think he's right that the best solution is to inline it. C bit shifting is notoriously error prone - I've seen this bug multiple times:

uint32_t a = ...;
uint32_t b = ...;
uint64_t c = (a << 32) | b;

The real problem is the name isn't very good. E.g. it could be u32_high_low_to_u64 or something. Might clearer. Certainly easily at kernel code levels of clarity.

(Really the naming issue comes from C not having keyword arguments but you can't do anything about that.)

[–] wizzim@infosec.pub 2 points 3 weeks ago (2 children)

I am not a C developer, but I found the "helper has a terrible name" and "it's not clear what the helper is doing" arguments a bit weak.

Who in they right mind does not think the helper creates a 32 bytes word by putting the 16 bytes of the first argument followed by the 16 bytes of the second one ?

[–] traceur201@piefed.social 33 points 3 weeks ago

It's bits, not bytes. And endianness is a huge consideration in systems programming. And it's basically Linus' whole role at this point to enforce extreme consistency and standards since the project is so large with so many contributors

[–] FizzyOrange@programming.dev 9 points 3 weeks ago* (last edited 3 weeks ago)

Yeah it actually is fairly common to have the high word first because humans unfortunately picked the wrong endianness, and integers are written in big endian.

E.g. what value would you expect from u16x2_to_u32(0x1122, 0x3344)? If you said 0x11223344...

Still, the rant is stupid because all that needs to happen is to fix the name.

Honestly it's really surprising that the kernel doesn't already have a library of reliably but manipulation functions for common stuff like this.