From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 9A1933858C54 for ; Wed, 24 May 2023 12:45:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9A1933858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684932309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=efEjRW8C9KaQN8YpTrUPnxtMeVXDXh89rkDuHo2Cq9s=; b=gUnTNnetQyykfQnsVaGCuvP6tf47iERcqoHoyCk0UVHuT6OTKxPEqwyPwQ7o3ns9i1hxkU kfs/TQZvboTv1K+T6Vsz76OudThPKd4QQ5Bhx22LWVlGkYnO0hV+j1Vyemx0ral+45Tn/M q04/o3r9buoNpmNh6qln3s49ssz7tek= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-616-vnlSv9zXNKexRadCMn00FQ-1; Wed, 24 May 2023 08:45:06 -0400 X-MC-Unique: vnlSv9zXNKexRadCMn00FQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C94CA8039BE; Wed, 24 May 2023 12:45:05 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8DFA6202696C; Wed, 24 May 2023 12:45:04 +0000 (UTC) From: Florian Weimer To: Sergey Bugaev Cc: Andreas Schwab , Siddhesh Poyarekar , libc-alpha@sourceware.org Subject: Re: [RFC PATCH 1/1] io: Add FORTIFY_SOURCE check for fcntl arguments References: <20230519213059.3812385-1-bugaevc@gmail.com> <20230519213059.3812385-2-bugaevc@gmail.com> <871qj6202r.fsf@mid.deneb.enyo.de> <87fs7myvxm.fsf@oldenburg.str.redhat.com> <87zg5uvuyz.fsf@oldenburg.str.redhat.com> <6831d3d3-786b-2ac3-5abf-dce24aa158a7@gotplt.org> <87h6s1x6rh.fsf@oldenburg.str.redhat.com> Date: Wed, 24 May 2023 14:45:03 +0200 In-Reply-To: (Sergey Bugaev's message of "Wed, 24 May 2023 15:37:16 +0300") Message-ID: <874jo1x5io.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Sergey Bugaev: > On Wed, May 24, 2023 at 3:18=E2=80=AFPM Florian Weimer wrote: >> We also generally do not prevent the use of compiler extensions in >> strict feature modes. I think this should use a compiler version check >> and maybe a fallback check against C17 compiler support if we do not >> need any extensions (assuming that all C17 compilers implement _Generic, >> so that an exception like the one you mentioned for GCC does not apply >> vis-a-vis C17). > > Do I understand this correctly? -- you want the check to be > > #if (__STDC_VERSION__ >=3D 201710L) || (__GNUC_PREREQ (4, 9) && > __STDC_VERSION__ >=3D 201112L) > > right? More like this: #if __STDC_VERSION__ >=3D 201710L) || __GNUC_PREREQ (4, 9) If you have GCC 4.9, __STDC_VERSION__ does not matter if you use __extension__ in front of _Generic (untested). Clang would benefit from another version conditional. But we may not need _Generic after all. > Why even care for compilers other than modern GCC (and Clang > pretending to be GCC), considering the fortifications use very > GCC-specific intrinsics (__builtin_*, attributes)? Some of us want to reproduce things with older compilers, for bisecting regressions for example. For that, the headers better remain compatible. And GCC 4.8 is still very widely used (although not with current GCC headers, admittedly). Thanks, Florian