linux-kernel - Thanks Palmer (& ChatGPT; I'm rubbish at mailing lists)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAPKFLCRrLYguS90i-c65o8S4x_QnmJYiJrkpJMzu2F8UsjnEBA@mail.gmail.com>
Date: Wed, 3 Sep 2025 15:16:35 +1000
From: Sebastian Ramadan <slay.sebbeh@...il.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Thanks Palmer (& ChatGPT; I'm rubbish at mailing lists)

Hi Palmer,

I recently followed the discussion around your make_u32_from_two_u16()
macro and the subsequent debate involving Linus. I wanted to reach out
and express my appreciation for the approach you took, particularly
from the perspective of embedded systems developers and strict ISO C
conformance.

Your macro encapsulates a pattern that, while seemingly simple, is
crucial for writing portable and reliable code across architectures
with different integer sizes — especially 16-bit platforms where
implicit integer promotions — or lack thereof, followed by shifts, can
lead to undefined behavior. This is a real concern for developers
working on constrained embedded environments, where assumptions about
int being 32 bits simply do not hold, not to mention organisations
that rely upon legalese specs and conformance to keep them out of
court, or from damaging equipment.

While Linus’s shorthand (a << 16) + b is indeed concise and familiar
within much of the kernel development ecosystem, it unfortunately
assumes platform characteristics that don’t hold universally,
potentially leading to subtle bugs and nonportable code. Your macro
helps enforce clarity and portability, and it encourages safer, more
reusable code that can benefit the broader community—especially those
working outside of the traditional GNU/Linux x86 or ARM environments.

Moreover, embracing such abstractions aligns well with modern software
engineering best practices: promoting code reuse, reducing
duplication, and improving maintainability. This ultimately decreases
the time spent debugging platform-specific corner cases and helps keep
the kernel codebase robust across the diverse hardware it supports.

I hope the community can continue to value and adopt these portable,
standards-compliant techniques alongside the kernel’s preferred coding
styles. Thanks again for contributing to this important conversation
and for your ongoing work on RISC-V and kernel development.

If you’re open to it, I’d love to discuss this further or help explore
ways to promote portability best practices in kernel patches.

Best regards,
Sebastian Ramadan