This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Continuing the UAPI split


On 07/11/2019 13:03, Elichai Turkel wrote:
> A rename to the structs/types so they won't collide with libc?
> Prioritizing POSIX conformance in the kernel(I think that ship has long sailed)?

hosted c code can only use linux api headers reliably
if those respect the iso c and posix rules.

linux should maintain a clean set of c headers (or
interface descriptions from which such headers can be
generated).

providing clean headers that work in both hosted and
freestanding environments is not trivial: e.g. the
former requires type definitions to use libc types,
the latter requires type definitions that don't depend
on the libc.

e.g. a possible approach is to use iso c implementation
reserved namespace for all linux api identifiers, so
it's entirely independent of libc and non-conflicting,
then libc headers can replicate declarations that it
wants to expose (with different names and libc types).
(there are other ways, but the current headers are hard
to use which affects a lot of users)

> Or just giving up and telling users they can't just directly include
> both libc headers and kernel headers?

including both libc and linux headers is fragile and
will break differently across the different linux
libc implementations.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]