From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21706 invoked from network); 3 May 2023 14:16:35 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 May 2023 14:16:35 -0000 Received: (qmail 19803 invoked by uid 550); 3 May 2023 14:16:32 -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 19753 invoked from network); 3 May 2023 14:16:31 -0000 Date: Wed, 3 May 2023 10:16:19 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230503141619.GW4163@brightrain.aerifal.cx> References: <20230501205037.29e42745@inria.fr> <20230501194121.GS4163@brightrain.aerifal.cx> <20230502085740.23ff20d5@inria.fr> <20230502155903.30bee099@inria.fr> <20230502232009.GT4163@brightrain.aerifal.cx> <20230503000045.GU4163@brightrain.aerifal.cx> <20230503111246.00ba409e@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230503111246.00ba409e@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] patches for C23 On Wed, May 03, 2023 at 11:12:46AM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > > Language/compiler baseline for building musl is not going to go up, so > > this complicates some things, especially implementing the int128 > > stuff. This will need pop_arg to call out to an arch-provided asm > > function that bypasses the C type system to get the nonexistent-type > > argument off the va_list and store it in a pair of uint64_t. > > I don't see that. `pop_arg` just uses `va_arg` and that in turn is > fixed to `__builtin_va_arg`. The proposed patches assume that if > `__SIZEOF_INT128__` is defined by the compiler that then the compiler > provides the `__int128` types and knows how to deal with them in > `__builtin_va_arg`. Is there anything wrong with that assumtion? Yes. We don't require a compiler that has an __int128. The feature set of the library is not allowed to vary depending on the compiler version it was built with. The only non-UB way to get an __int128 out of a va_list if the compiler has no idea there's such a thing as __int128 is to write asm that bypasses the C type system. There can be a "generic" version of this TU, I guess, for archs where __int128 has always been part of the arch ABI definition, that just uses a C function calling va_arg; this would also be suitable for folks reusing the code in places like wasm where an asm implementation isn't suitable and where they have more control over the tooling. > > As above, strict conformance to outdated versions of the standard is > > just not a priority. musl's claim/target is conformance to current > > versions only and sometimes, on a case-by-case basis, partial > > support for older ones. > > Yes. But this here is really something to consider. Legacy executables > that are linked dynamically may behave semantically different with > this patch. This might even have security implications. E.g within > musl itself in inet_aton.c there is a use with a base of `0` that > could perhaps be abused to do spoofy things. One thing that could be done here, but I'm not sure if it's useful or appropriate, is linking an object file defining a symbol named something like __c23_profile with value 1 into the application or shared library built in c23 mode. This would override (via interposition) a definition with the value zero internal to libc, and could be used to switch on incompatible features like this. I'm skeptical whether this kind of thing is something we should do or want to do, but it's at least something we could consider... It seems unfortunate that the committee did not consider this adequately. It would have made a lot more sense to leave the behavior of base==0 alone and add new behaviors with base=-1 or something. But FWIW the same kind of incompatible change already happened with floating point in the past (strtod/scanf %e/f/g consuming hex floats rather than reading "0x..." as 0) and the world didn't explode. Rich