From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id d8d3fdbd for ; Tue, 28 Jan 2020 13:39:49 +0000 (UTC) Received: (qmail 20387 invoked by uid 550); 28 Jan 2020 13:39:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20369 invoked from network); 28 Jan 2020 13:39:47 -0000 Date: Tue, 28 Jan 2020 08:39:35 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200128133935.GF30412@brightrain.aerifal.cx> References: <20200119121247.37310-1-info@bnoordhuis.nl> <20200124140113.GU30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Re: [PATCH] add statx On Tue, Jan 28, 2020 at 09:59:56AM +0100, Ben Noordhuis wrote: > On Fri, Jan 24, 2020 at 3:01 PM Rich Felker wrote: > > > > On Fri, Jan 24, 2020 at 09:38:49AM +0100, Ben Noordhuis wrote: > > > > > > Can I get some feedback on this patch, even if it's just "no because"? Thanks. > > > > Sorry aboout that; I'd just had my mind on other things and hadn't > > taken the time to make a good review yet. > > Thanks for the feedback and no worries, I'm no saint in that regard either. > > Before I post a v2, did I understand the following issues correctly? > > 1. Switch _GNU_SOURCE || _BSD_SOURCE -> just _GNU_SOURCE? Yes. > FWIW, _BSD_SOURCE currently exposes the AT_STATX_* flags in fcntl.h. Being that they're "namespaced" under AT_*, I don't think this is a big deal. I was generally of the opinion that AT_* flags make sense to always expose since they might be used with standard interfaces as extensions, rather than with nonstandard interfaces. Even though AT_STATX_* seem statx-exclusive, maybe they make sense as extension flags to fstatat too? In any case I think we can leave any consideration of a change here for later; it's separate from adding statx(). > 2. uint64_t -> unsigned long long guarded by #ifdef __GNUC__ > __extension__? Or just leave it as-is? long long does not use __extension__ guard in musl, but I think we should stick with the semantically correct types, [u]intNN_t. > 4. An ENOSYS fallback to fstatat()? glibc's fallback returns EINVAL > for AT_* flags it doesn't understand and ignores all STATX_* flags: it > sets stx_mask to STATX_BASIC_STATS, fills in stx_uid/stx_gid/etc. and > sets stx_btime to zero. Does that sound reasonable? Sounds right. Note that filling in stx_[r]dev_{major,minor} requires the sys/sysmacros.h major()/minor()/ macros since statx oddly separated them out of dev_t. I don't think setting btime to 0 is strictly necessary, but since it's in the range of the struct that's unconditionally present, it's okay to do so, and perhaps guards against info leaks from old stack contents. Rich