From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id C32BD3858D39; Sat, 11 Dec 2021 17:10:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C32BD3858D39 Received: by mail-wr1-x42a.google.com with SMTP id t9so20018106wrx.7; Sat, 11 Dec 2021 09:10:13 -0800 (PST) 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=H+vDbn3D4WcDUUJUYjQJv1mwv9WWeCPHvMGTipX3GOk=; b=zw1DXuVaXWkpe/kl+wrIY84g7RPwOmga0HT5RkJ40KN5IcwkiqHyr6sjZ//ScywQ1c ctFsh84uD0igq2LcezE55F8jcN4DSK+5FSWpIDx6lLBS7RqALVbgArm125jINOeVexzh 8HfF7SMMXAZZkrxRvkokp7i7wwoK8Sr/PQSBG5JIvjEV1IC2y5LRQCqVyrbDuLwh9aar Dbpbg/6YD/YG3qtWE0hBNYvtj6+CjfXyAIbBXlryz4vyHTEKaHk7FV/xMgFbSZ6agff4 3WJDiCr0cgeo/dAD3CVCj3SR3Mn7lYAbVgp7bdN87RrCfwzjLQXjj5/kcz2mNADLQJl5 ER8w== X-Gm-Message-State: AOAM5316I3zrmkM22yxBDNR8REDkgx4hamTHQEWlVMg10a49iiiGWFjf 5vlD7bqwfxP0uV4E37qK/8fo0Vl9L/hENFbU7lw= X-Google-Smtp-Source: ABdhPJyafdTGsSRAPOjLwwAi34JlU+XgPqdR3ZVrz/wmgFn9gJoWjHpaz9QB9dLKPeUV0/MGq427VUAXn+5iyMCwkDU= X-Received: by 2002:a5d:64c6:: with SMTP id f6mr21094710wri.568.1639242612785; Sat, 11 Dec 2021 09:10:12 -0800 (PST) MIME-Version: 1.0 References: <3913529E-3CB1-4758-B675-A8862869B238@adacore.com> In-Reply-To: <3913529E-3CB1-4758-B675-A8862869B238@adacore.com> From: Jonathan Wakely Date: Sat, 11 Dec 2021 17:09:57 +0000 Message-ID: Subject: Re: [PATCH] #undef isblank before def or decl in libstdc++ headers To: Olivier Hainque Cc: Jonathan Wakely , "libstdc++" , gcc-patches X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 17:10:15 -0000 On Sat, 11 Dec 2021, 10:56 Olivier Hainque via Libstdc++, < libstdc++@gcc.gnu.org> wrote: > (Thanks for your feedback Jonathan) > > > On 10 Dec 2021, at 19:24, Jonathan Wakely wrote: > > > > I'm curious why _GLIBCXX_USE_C99_CTYPE_TR1 is not defined if VxWorks > > has isblank, the configure check is: > > Oh, hmm, very good point. The reason was that the definition > of isblank is conditioned on _C99/_HAS_C9X as well, so the need > for which we had introduced the definition in os_defines.h > would better be generalized. > > * config/vxworks.h (VXWORKS_OS_CPP_BUILTINS): Define > _C99 for C++. > > --- a/gcc/config/vxworks.h > +++ b/gcc/config/vxworks.h > @@ -328,6 +328,10 @@ extern void vxworks_asm_out_destructor (rtx symbol, > int priority); > if (!flag_isoc99 && !c_dialect_cxx()) \ > builtin_define ("_ALLOW_KEYWORD_MACROS"); \ > } \ > + /* C++ support relies on C99 features. Make sure they are \ > + exposed by the system headers. */ \ > + if (c_dialect_cxx()) \ > + builtin_define("_C99"); \ > } \ > while (0) > > > Works with the two libstdc++ changes reverted, and gives > "configure" a better view of what's there. > > Makes sense? Yes. I can't approve patches outside libstdc++, but that looks definitely correct for C++11 and later, because C++11 incorporates the whole C99 library by reference. So if that macro is needed to get the C99 library (because the vxworks libc doesn't check the__cplusplus macro and enable C99 features that way), then I agree _C99 should be defined for C++11. Defining it for C++11 is sufficient to solve the isblank problem, because std::isblank is only declared for C++11 and later. (std::tr1::isblank is declared for C++98 if the C library supports it, but nobody really cares about TR1 nowadays, and probably hardly anybody cares about C++98). Defining _C99 is not strictly correct for C++98 mode, because C++98 incorporates the C89 library by reference. But as you noted in the earlier patch, libstdc++ likes to have full C99 facilities available even for C++98 mode (so it can use them for std::tr1 features, among other things). So I think defining it even for C++98 is fine too.