Linux

9406 readers

271 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

141

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

submitted 1 month ago by Sunshine@piefed.ca to c/linux@programming.dev

22 comments fedilink hide all child comments

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

[–] FizzyOrange@programming.dev 18 points 1 month ago (4 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 0 points 1 month ago (3 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 31 points 1 month ago (1 children)

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

[–] wizzim 1 points 1 month ago

Thanks for the explanation.

I totally forgot about the endianness.

load more comments (1 replies)