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 080B43839C5F for ; Mon, 16 May 2022 15:50:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 080B43839C5F Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-364-WVAyi7_9PTmpzR4QeEPKsw-1; Mon, 16 May 2022 11:50:13 -0400 X-MC-Unique: WVAyi7_9PTmpzR4QeEPKsw-1 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-2f4dfd09d7fso133253867b3.0 for ; Mon, 16 May 2022 08:50:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hreS9IBjSGJRvoZDBnlCNgMNOXO2Ul/bL8HrefRMGyI=; b=Mqx+78zVfcJZi7Iv/Lern4HJeCEEI4pwgM4QFHtbhx9QYHe81LlZM4GHtJfb7AjNnJ RWoOuM+kWiwurVmduklW3i0nHfzCFz1KLidbfJ9Ioxsyp5erzSoHb2QQbuVmlF1a6xqu xoAcx5yERvDma2fVPcEMEy3qZmKITBpSVCCrdAra53TFwMveOawmgxp2Ai7siQFnOyrf r7HiStlh1P9AcI73xIXJ9xgjmX0Sd51cppwrgJHd0vWqxGl+3UELo34jRyQ+DO5rGzaO Sp98AYUBQVm0OZ14umyAH0u9RgR4aKwrBczfLv6YeEHfiwWEWjEjtoSVpxZFKZE5Bn3X /X1g== X-Gm-Message-State: AOAM5304fTe/Kg7d9k2KOWM8OsZO/qSBn8tygk+yO253r/MeTqgh4iUv bDoR6Yj8DRlfjl63bFu2vzsYSWAmUdCt4OQlhHPBwmGLsbOI9WpOuVKjbnTI/MRVXGlvve4W8+4 a4jojrcalY/f9qhH0LUD08c7joGGjFme0ldnj X-Received: by 2002:a0d:d4c7:0:b0:2ff:1578:11eb with SMTP id w190-20020a0dd4c7000000b002ff157811ebmr2013556ywd.206.1652716213225; Mon, 16 May 2022 08:50:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPjNG86+bY/iKNKW+qPS3ysub5PGdCDZSFx369cTKSQFBIg1glf2hH+AgtaI7ZcI/72vjStFxgVuyRijLzEj8= X-Received: by 2002:a0d:d4c7:0:b0:2ff:1578:11eb with SMTP id w190-20020a0dd4c7000000b002ff157811ebmr2013533ywd.206.1652716213050; Mon, 16 May 2022 08:50:13 -0700 (PDT) MIME-Version: 1.0 References: <20220514064608.lonhluprui6ypv4k@google.com> In-Reply-To: <20220514064608.lonhluprui6ypv4k@google.com> From: Jonathan Wakely Date: Mon, 16 May 2022 16:50:02 +0100 Message-ID: Subject: Re: [PATCH] Check for ISO C compilers should also allow C++ To: Fangrui Song Cc: Joseph Myers , Florian Weimer , GNU C Library X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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 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: Mon, 16 May 2022 15:50:16 -0000 On Sat, 14 May 2022 at 07:46, Fangrui Song wrote: > > On 2022-05-13, Jonathan Wakely via Libc-alpha wrote: > >On Fri, 13 May 2022 at 18:28, Joseph Myers wrote: > >> > >> On Fri, 13 May 2022, Jonathan Wakely via Libc-alpha wrote: > >> > >> > Tested x86_64-linux. > >> > > >> > There is a suggestion[1] to make clang++ stop defining __STDC__ but it's > >> > blocked by this. The clang++ change will still be blocked while old > >> > Glibc versions are still in use, but we can start the clock ticking by > >> > fixing Glibc now. > >> > > >> > [1] https://discourse.llvm.org/t/rfc-stop-defining-the-stdc-and-related-macros-in-c-mode/62468/1 > >> > > >> > >From a quick grep, I don't think any other places in Glibc need a > >> > similar change. Florian pointed out that gnulib overrides > >> > and so should make the same change in its version. > >> > >> The change seems sane. While we don't document what extensions (beyond > >> C90 / C++98) are needed to use glibc's headers (e.g. long long, flexible > >> array members, anonymous structs / unions; in at least some cases, > >> alignment attributes and asm redirection of functions), I see no reason > >> defining __STDC__ in C++ should be such a required extension. > > > >Right. Its meaning in ISO C++ is entirely implementation-defined, and > >G++ doesn't document any particular meaning for it, and clang++ > >doesn't either AFAIK, and follows a slightly different set of rules > >for when it's defined (see the link above). So in C++ the only thing > >that __STDC__ being defined tells you is that __STDC__ is defined :-) > >That's not a very useful thing to test for in isolation. > > > > I agree with the spirit of the clang RFC but I am sad to know that glibc sys/cdefs.h blocks it. > Thanks for sending the patch! > > It seems that the subject may be clearer if starting with ": ..." > > In addition, It will be clearer if the token `__STDC__` is mentioned on the subject line. > > Reviewed-by: Fangrui Song I made the suggested changes to the commit message and pushed the patch, thanks for the reviews.