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 8b6d4fc7 for ; Tue, 28 Jan 2020 13:19:02 +0000 (UTC) Received: (qmail 11807 invoked by uid 550); 28 Jan 2020 13:19:00 -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 11788 invoked from network); 28 Jan 2020 13:19:00 -0000 Date: Tue, 28 Jan 2020 08:18:45 -0500 From: Rich Felker To: Florian Weimer Cc: musl@lists.openwall.com Message-ID: <20200128131844.GD30412@brightrain.aerifal.cx> References: <20200119121247.37310-1-info@bnoordhuis.nl> <20200124140027.GT30412@brightrain.aerifal.cx> <878slw3mdo.fsf@oldenburg2.str.redhat.com> <20200124155458.GW30412@brightrain.aerifal.cx> <87k15g25q4.fsf@oldenburg2.str.redhat.com> <20200124162910.GX30412@brightrain.aerifal.cx> <87blqneuci.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87blqneuci.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] [PATCH] add statx On Tue, Jan 28, 2020 at 11:41:33AM +0100, Florian Weimer wrote: > * Rich Felker: > > >> >> We received feedback that our headers are not useful due to the > >> >> __u64/uint64_t mismatch. > >> >> > >> >> >> >> > >> > > >> > 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? > >> > >> Yes, printf format strings. 8-( > > > > Why not let ppl get the warnings and fix them by casting to an > > appropriate type to print. I prefer [u]intmax_t anyway to avoid the > > PRIu64 etc. mess that makes your format strings unreadable and that > > interferes with translation (*). > > I'm concerned that such casts hide or even introduce bugs, like casting > tv_sec to int. As you've found, people will do incorrect casts regardless, in places where it makes a bigger difference than here, where using fixed basic types isn't an option. I don't think the solution is throwing away proper semantic use of types. > Here's an example from the MySQL sources: > > int my_timeval_to_str(const struct timeval *tm, char *to, uint dec) > { > int len= sprintf(to, "%d", (int) tm->tv_sec); > if (dec) > len+= my_useconds_to_str(to + len, tm->tv_usec, dec); > return len; > } In the particular case of time, we should probably teach GCC to issue warnings (-Wy2038?) for casts from an expression whose type was declared via a typedef named time_t (I know GCC tracks knowledge of the typedef name used, since it shows it in other warnings) to a type smaller than 64-bit. > That's why the kernel always uses unsigned long long for __u64, which > seems a reasonable trade-off to me. It will make porting to 128-bit > architectures difficult. But I think we should focus on the > architectures we have today. I disagree strongly with the last sentence. Designing an *API* in a way that's not compatible with anything but long long == 64-bit is bad API design. Arguably you could get into having something like k_[u]intNN_t or similar, and use these, but I feel like that's just gratuitous ugliness. The userspace type for 64-bit fixed-size fields is [u]int64_t and we should be promoting its consistent usage, not fragmenting things around kernel uapi mistakes. (Perhaps kernel uapi headers should be fixed so that, when __KERNEL__ is not defined, they include and define __u64 etc. in terms of the stdint types?) Rich