Linus Rejects "Size Of Member" Change From Linux 5.5 Kernel

[dEnigma]

Who fucking cares if some internal kernel macros are unified under a common name or not and what nam it would be?
How is this newsworthy to end-users?

Is there really nothing more interesting to write about? Maybe open source games or stuff like that?

You're free to ignore articles that don't interest you, while people who actually are interested can read the article, with no harm done to you.

[lucrus]

Who fucking cares if some internal kernel macros are unified under a common name or not and what nam it would be?

There are a lot of people who do care, because the whole thing has even a name: macro-naming-freedom, e.g. the next big problem we'll face after init-freedom...

[Neuro-Chef]

Everyone knows it's how you use the macro that's important

But if size isn't that important, then why are there multiple ways to determine it?

[ermo]

1./ Consolidating the code to use just one well-implemented/-documented/-understood macro seems desirable in and of itself?

2./ If the above is accepted as sound and valid, why not simply (re-)name the new macro sizeof_field, replace the existing macro invocations (basically re-using the already existing google branch) and be done with it?

Puerile chitchat aside, what am I missing?

[cjcox]

Removing sizeof_member.... err all sizeof... err size... and length... and len.... because we know what you mean.

PC Linux kernel with all vars and and function names limited to just the single letters a-w, y-z and up to 2 numbers following. Thus, a02 is ok. but not xx69.

[cjcox]

Another thought, make a mandatory hook to userland, call it sizeof_memberd (ensures it will happen).

[betam4x]

I actually talked about this with a teenager, and they said “hah, you said member”. It donned on me that I am getting old at just 22.

On a more serious note, Linus makes a perfectly good point. There is no good reason it can't be sizeof_field like it already is elsewhere, and "field" is a perfectly good name for the parts of a struct, at least as much as "member".

Or maybe Linus could have a sense of humor and allow it.

[betam4x]

On an unrelated note, it always baffles me why certain groups of developers like to use underscores in their functions. IMO sizeOfMember or SizeOfMember are both quicker and easier to type. The distance of the _ character is much further than the shift key. There are also fewer characters.

[F.Ultra]

On an unrelated note, it always baffles me why certain groups of developers like to use underscores in their functions. IMO sizeOfMember or SizeOfMember are both quicker and easier to type. The distance of the _ character is much further than the shift key. There are also fewer characters.

It's because camelCase creates readability problems. When you read+evaluate tons of code it's far far easier to quickly see what count_active_users() vs countActiveUsers() does due to how our brains parses text).

[microcode]

While 'field' is a generic term, their name in the C language is 'member'.

I have read the standard, but the standard came after the language. Structs are records, records have fields, structs might have members, but members are fields.