[PATCH v3] Many pages: Document fixed-width types with ISO C naming

[Alejandro Colomar]

Hi Linux,

On 8/25/22 02:52, Linus Torvalds wrote:
> On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
>>
>> I'm trying to be nice, and ask for review to make sure I'm not making
>> some big mistake by accident, and I get disrespect?  No thanks.
> 
> You've been told multiple times that the kernel doesn't use the
> "standard" names, and *cannot* use them for namespace reasons, and you
> ignore all the feedback, and then you claim you are asking for review?

This patch is not about kernel, but about the section 2 and 3 manual 
pages, which are directed towards user-space readers most of the time. 
Admittedly, some syscalls are only callable from within the kernel 
itself, but that's very rare.

[...]

> 
> The fact is, kernel UAPI header files MUST NOT use the so-called standard names.

I don't know for sure, and I never pretended to say otherwise.  But what 
IMHO the kernel could do is to make the types compatible, by typedefing 
to the same fundamental types (i.e., long or long long) that user-space 
types do.

> 
> We cannot provide said names, because they are only provided by the
> standard header files.
> 
> And since kernel header files cannot provide them, then kernel UAPI
> header files cannot _use_ them.
> 
> End result: any kernel UAPI header file will continue to use __u32 etc
> naming that doesn't have any namespace pollution issues.
> 
> Nothing else is even remotely acceptable.
> 
> Stop trying to make this something other than it is.
> 
> And if you cannot accept these simple technical reasons, why do you
> expect respect?
> 
> Why are you so special that you think you can change the rules for
> kernel uapi files over the *repeated* objections from maintainers who
> know better?

No sorry, if someone understood this patch as changing anything in UAPI, 
it is not.

Cheers,

Alex

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20220825/758ee82a/attachment.sig>