|
Message-ID: <20200124155458.GW30412@brightrain.aerifal.cx> Date: Fri, 24 Jan 2020 10:54:58 -0500 From: Rich Felker <dalias@...c.org> To: Florian Weimer <fweimer@...hat.com> Cc: musl@...ts.openwall.com Subject: Re: [PATCH] add statx On Fri, Jan 24, 2020 at 04:27:47PM +0100, Florian Weimer wrote: > * Rich Felker: > > > This is under BSD||GNU (i.e. DEFAULT||ALL) rather than just under the > > latter. Is there a reason for that? Generally the extensions that are > > pretty clearly Linux-only, as opposed to something that other > > POSIX-based OS's are likely to adopt, are put under GNU/ALL to > > discourage their use without intent and to avoid namespace clutter. > > statx is not Linux-specific in glibc, but also available on Hurd. OK, well GNU/Linux-specific. :-) Some ppl find _GNU_SOURCE odd for stuff that comes from Linux not GNU, but in this case it seems pretty appropriate since GNU and Linux are the two systems doing it. > We received feedback that our headers are not useful due to the > __u64/uint64_t mismatch. > > <https://sourceware.org/bugzilla/show_bug.cgi?id=25292 > <https://sourceware.org/ml/libc-alpha/2019-12/msg00631.html> Uhg. That change seems unfortunate since it's incompatible with theoretical future archs having 128-bit long long -- an idea I'm not much a fan of, but don't actually want to preclude. Is there a reason to actually care about compatibility with the kernel types? It's not like both struct definitions can be included in the same source anyway; the tags would clash. Using the canonical uintN_t types makes more sense from an API perspective, I think; kernel assumptions about types should not leak into an API intended to be clean and shared with non-Linux implementations. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.