Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/3/21 13:32, Adhemerval Zanella via Libc-alpha wrote:
We (musl) don't have an equivalent header or __-prefixed versions of
these types.

FWIW I don't think stdint.h exposes anything that would be problematic
alongside arbitrary use of kernel headers.


Also, per glibc's bits/types.h:

/*
  * Never include this file directly; use <sys/types.h> instead.
  */

it's not permitted (not supported usage) to #include <bits/types.h>.
So I think the above patch is wrong for glibc too. As I understand it,
this is general policy for bits/* -- they're only intended to work as
included by the libc system headers, not directly by something else.

You are right, the idea is to allow glibc to create and remove internal headers.

As a general rule yes, but we could make a deal that some specific bits headers are permanent API for use by things like this. They probably should be less of a dumping ground than bits/types.h though.

I really don't think adding such constraints really would improve the project
in long term, we already have issues about the need to support some internal
symbols that were exported by accident.


I think there are a few headers that should be safe to include from the kernel.

Could anyone foresee any problem that could arise by including any of the following headers in kernel code?:

<stdint.h>
<stddef.h>

They are the intended interface, and they only provide macros and types but not functions, and there should be no need to require libcs to define another identical stable interface. If there's an existing program that would break by including any of those in uapi headers, I'm curious to see that program.

Of course, the kernel already defined some of the macros defined there, but the solution would be easy: remove the redefinitions, since they should be defined to equivalent code (e.g., offsetof(), NULL; although these are from <stddef.h>, which for this change would be unnecessary, but if <stdint.h> can be used within the kernel, a next step could be to rely on libc <stddef.h>)

Thanks,
Alex

--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux