From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by sourceware.org (Postfix) with ESMTPS id 9BD7D3858039 for ; Wed, 5 Jan 2022 20:12:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BD7D3858039 Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id 573TnswUAlW5q5CeHnbCJ3; Wed, 05 Jan 2022 20:12:41 +0000 Received: from kylheku.com ([70.79.182.7]) by cmsmtp with ESMTPA id 5CeFnvMrpmX1k5CeGnoaiE; Wed, 05 Jan 2022 20:12:41 +0000 X-Authority-Analysis: v=2.4 cv=Fe4keby6 c=1 sm=1 tr=0 ts=61d5fbb9 a=pMSlDXUwMa7SJ1EIez8PdQ==:117 a=pMSlDXUwMa7SJ1EIez8PdQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=DghFqjY3_ZEA:10 a=5KLPUuaC_9wA:10 a=7mOBRU54AAAA:8 a=17k6n4LIiNVrPyKMhDQA:9 a=QEXdDO2ut3YA:10 a=wa9RWnbW_A1YIeRBVszw:22 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from ) id 1n5CeF-0005GJ-Im; Wed, 05 Jan 2022 12:12:39 -0800 To: Paul Eggert Subject: Re: Best practices in regard to =?UTF-8?Q?-D=5FTIME=5FBITS=3D=36?= =?UTF-8?Q?=34?= X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 05 Jan 2022 12:12:39 -0800 From: Kaz Kylheku Cc: Sam James , Fangrui Song via Libc-alpha , toolchain@gentoo.org, "Andreas K. Huettel" , chewi@gentoo.org In-Reply-To: <3e6da354-70ec-07c6-4df4-1c995d9f927e@cs.ucla.edu> References: <33e9ae8d-8b29-19d9-8747-cb8e96490205@cs.ucla.edu> <3e6da354-70ec-07c6-4df4-1c995d9f927e@cs.ucla.edu> Message-ID: <22016c8224e8fbf87cb15489188c8856@mail.kylheku.com> X-Sender: kaz@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4xfAG4jAcJT2DQbG+EjZKTQPbwJCckcTdif6yONStbC3xL+t/gtYOZEb9UFMlPGCYCjxwdNVMDIzo9OYoUAz6zp7Y67esAI4yPsWcZ8IwAQ8yccEcFh4Af Bns5YY/p23lACgeZnQhF3+88buE17lB3C1jm0hkVTm7LmBOuvPZhaGCN2mpHvc2aW//TPCugCB8j7PvS9EeggtsxymSerDRsIPYtWHUYlnEbTiuU5SGM3Jcv dd8Wu/hXrEV0Fqe55uDYQI8hJlCQ2E7c3NVg4oudtuLxlS4SHLwY0ELLv+gBNXkBwcbaeWJvEBkRFys9aONx41AEkrylxbcCf6+d2rHBGiI= X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS, KAM_NUMSUBJECT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 20:12:43 -0000 On 2022-01-04 20:43, Paul Eggert wrote: > On 1/4/22 16:53, Sam James wrote: > >> FWIW, we've hit issues in Gentoo with wget/gnutls: >> https://bugs.gentoo.org/828001 . > > Thanks for the heads-up. > > Yes, not surprised about that, as mixing 64-bit time_t apps with > 32-bit time_t libraries is a recipe for trouble if the APIs depend on > time_t. For apps that use such libraries, it really has to be a big > bang: configure all that stuff with --disable-year2038 -D_TIME_BITS=32 > before, and with --enable-year2038 CFLAGS=-D_TIME_BITS=64 after. > >> https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration I looked at this Wiki page and one thing stands out. I would recommend to the Gentoo people to forget about CPPFLAGS, and just use CFLAGS, even for -D material. If you put -D_TIME_BITS=64 into CFLAGS, you then don't have to deal with packages that perfectly well honor CFLAGS, but not CPPFLAGS. People don't know about CPPFLAGS. It seems to be just something invented by GNU Make, referenced in some of its built-in recipes. Getting all upstream packages to recognize CPPFLAGS (or else patching them locally) is just a lot of make-work (pun intended). I'm also aware of a historic *ad hoc* practice of using CPPFLAGS for C++ CFLAGS; i.e. that for which CXXFLAGS is a better practice. For what it's worth, POSIX's description of make mentions no CPPFLAGS, but does mention CFLAGS, LDFLAGS. (It also doesn't mention LDLIBS, another separation variable, but that I suspect is much more entrenched than CPPFLAGS, and the separation is quite essential: you need to do that any time you specify additional -l arguments for linking.) GNU's built-in rules do some nonsensical things like: LINK.c := $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) (If CPPFLAGS is needed all the way through linking C, what purpose does it serve separate from CFLAGS? And if I'm writing my own linking recipe, do I have to reproduce this?) CPPFLAGS is something that would be useful for calling a standalone C preprocessor that doesn't understand compiler options. But: You don't need that in a GCC environment, because you can call gcc with options that perform preprocessing only, and still pass other options specific to compiling. Not only that, but GNU cpp is tolerant to gcc options not pertaining to preprocessing: No problem: $ echo | cpp -fstrict-aliasing > /dev/null $ echo | cpp -fNoNExistent > /dev/null cpp: error: unrecognized command line option ‘-fNoNExistent’; did you mean ‘-fno-ident’? You don't need CPPFLAGS in a non-GCC environment with GNU make, because you can easily do some GNU Make text processing to separate the preprocessor options, if you need them. Proof-of-concept demo: $ make CFLAGS="-Wall -I/path/to/include -UMAC -DFOO=bar -o foo.o -lm" cpp_only_flags == -I/path/to/include -UMAC -DFOO=bar Source: cpp_only_flags := $(foreach arg, \ $(CFLAGS), \ $(or $(filter -D%,$(arg)), \ $(filter -U%,$(arg)), \ $(filter -I%,$(arg)), \ $(filter -iquote%,$(arg)), \ $(filter -W%,$(arg)), \ $(filter -M%,$(arg)))) \ $(CPPFLAGS) # also pull this in all: @echo cpp_only_flags == $(cpp_only_flags) In an application, if you want separated C preprocessing flags, that is what you have to do; you can't assume that you're built in a distro environment which will hand them to you in a separate CPPFLAGS variable.