public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Kamil Rytarowski <n54@gmx.com>
Cc: Gerald Pfeifer <gerald@pfeifer.com>,
	Matthew Bauer <mjbauer95@gmail.com>,
	libstdc++@gcc.gnu.org,	gcc-patches@gcc.gnu.org,
	Maya Rashish <maya@netbsd.org>
Subject: Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream
Date: Tue, 07 Jan 2020 00:28:00 -0000	[thread overview]
Message-ID: <20200107002804.GN490107@redhat.com> (raw)
In-Reply-To: <bdd730b9-db6d-a78b-6924-d2db56761b5b@gmx.com>

On 07/01/20 00:18 +0100, Kamil Rytarowski wrote:
>On 06.01.2020 16:34, Jonathan Wakely wrote:
>> On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
>>> Hi Matthew,
>>>
>>> On Mon, 4 Feb 2019, Matthew Bauer wrote:
>>>> The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
>>>> have changed their ctype.h definition. It was updated in their intree
>>>> libstdc++-v3 but not in the GCC one. My understanding is this is a
>>>> straightforward rewrite. I've attached my own patch, but the file can
>>>> be obtained directly here:
>>>>
>>>> http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h
>>>>
>>>>
>>>> With the attached patch, libstdc++-v3 can succesfully be built with
>>>> NetBSD headers (along with --disable-libcilkrts).
>>>
>>> I noticed this has not been applied yet, nor seen a follow-up?, and also
>>> noticed it went to the gcc-patches list, but not libstdc++@gcc.gnu.org.
>>>
>>> Let me re-address this to libstdc++@gcc.gnu.org in the hope the
>>> maintainers there will have a look.
>>>
>>> Gerald
>>
>>> diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>>> b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>>> index ff3ec893974..21eccf9fde1 100644
>>> --- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>>> +++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>>> @@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>>   /// @brief  Base class for ctype.
>>>   struct ctype_base
>>>   {
>>> -    // Non-standard typedefs.
>>> -    typedef const unsigned char*    __to_type;
>>>
>>>     // NB: Offsets into ctype<char>::_M_table force a particular size
>>>     // on the mask type. Because of this, we don't use an enum.
>>> -    typedef unsigned char          mask;
>>>
>>> #ifndef _CTYPE_U
>>> -    static const mask upper        = _U;
>>> -    static const mask lower     = _L;
>>> -    static const mask alpha     = _U | _L;
>>> -    static const mask digit     = _N;
>>> -    static const mask xdigit     = _N | _X;
>>> -    static const mask space     = _S;
>>> -    static const mask print     = _P | _U | _L | _N | _B;
>>> -    static const mask graph     = _P | _U | _L | _N;
>>> -    static const mask cntrl     = _C;
>>> -    static const mask punct     = _P;
>>> -    static const mask alnum     = _U | _L | _N;
>>> +    // Non-standard typedefs.
>>> +    typedef const unsigned char*    __to_type;
>>> +
>>> +    typedef unsigned char    mask;
>>> +
>>> +    static const mask upper    = _U;
>>> +    static const mask lower    = _L;
>>> +    static const mask alpha    = _U | _L;
>>> +    static const mask digit    = _N;
>>> +    static const mask xdigit    = _N | _X;
>>> +    static const mask space    = _S;
>>> +    static const mask print    = _P | _U | _L | _N | _B;
>>> +    static const mask graph    = _P | _U | _L | _N;
>>> +    static const mask cntrl    = _C;
>>> +    static const mask punct    = _P;
>>> +    static const mask alnum    = _U | _L | _N;
>>> #else
>>> -    static const mask upper        = _CTYPE_U;
>>> -    static const mask lower     = _CTYPE_L;
>>> -    static const mask alpha     = _CTYPE_U | _CTYPE_L;
>>> -    static const mask digit     = _CTYPE_N;
>>> -    static const mask xdigit     = _CTYPE_N | _CTYPE_X;
>>> -    static const mask space     = _CTYPE_S;
>>> -    static const mask print     = _CTYPE_P | _CTYPE_U | _CTYPE_L |
>>> _CTYPE_N | _CTYPE_B;
>>> -    static const mask graph     = _CTYPE_P | _CTYPE_U | _CTYPE_L |
>>> _CTYPE_N;
>>> -    static const mask cntrl     = _CTYPE_C;
>>> -    static const mask punct     = _CTYPE_P;
>>> -    static const mask alnum     = _CTYPE_U | _CTYPE_L | _CTYPE_N;
>>> +    typedef const unsigned short*    __to_type;
>>> +
>>> +    typedef unsigned short    mask;
>>> +
>>> +    static const mask upper    = _CTYPE_U;
>>> +    static const mask lower    = _CTYPE_L;
>>> +    static const mask alpha    = _CTYPE_A;
>>> +    static const mask digit    = _CTYPE_D;
>>> +    static const mask xdigit    = _CTYPE_X;
>>> +    static const mask space    = _CTYPE_S;
>>> +    static const mask print    = _CTYPE_R;
>>> +    static const mask graph    = _CTYPE_G;
>>> +    static const mask cntrl    = _CTYPE_C;
>>> +    static const mask punct    = _CTYPE_P;
>>> +    static const mask alnum    = _CTYPE_A | _CTYPE_D;
>>> #endif
>>> #if __cplusplus >= 201103L
>>> -    static const mask blank     = space;
>>> +    static const mask blank    = space;
>>> #endif
>>>   };
>>>
>>> diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
>>> b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
>>> index ed3b7cd0d6a..33358e8f5d8 100644
>>> --- a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
>>> +++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
>>> @@ -38,11 +38,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>>
>>> // Information as gleaned from /usr/include/ctype.h
>>>
>>> -  extern "C" const u_int8_t _C_ctype_[];
>>> -
>>>   const ctype_base::mask*
>>>   ctype<char>::classic_table() throw()
>>> -  { return _C_ctype_ + 1; }
>>> +  { return _C_ctype_tab_ + 1; }
>>
>> The first patch attached to PR 64271 (i.e.
>> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34254 ) does that
>> differently. Is it safe to make this change unconditionally?
>>
>
>This file is NetBSD only (at least in theory) and we likely can do the
>right think without conditional build here.

Yes, it's NetBSD-specific, but it's used for multiple versions of
NetBSD.

The patch in PR 64271 only uses _C_ctype_tab_+1 when _CTYPE_BL is
defined, i.e. for newer versions of NetBSD. For older versions, it
still uses _C_ctype_.

So my question is whether _C_ctype_tab_+1 does the right thing for all
versions of NetBSD, or only for newer ones.

  reply	other threads:[~2020-01-07  0:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFnZKr1EPETS4CNu0rHwkhWSGRDt_e0TJpjUPTfSeDywDXyVRg@mail.gmail.com>
2019-12-21 23:37 ` Gerald Pfeifer
2019-12-22 14:06   ` Kamil Rytarowski
2019-12-23 10:33   ` Jonathan Wakely
2020-01-06 15:24   ` Jonathan Wakely
2020-01-06 22:20     ` Kamil Rytarowski
2020-01-07  0:26       ` Jonathan Wakely
2020-01-07  0:31         ` Kamil Rytarowski
2020-01-07 15:40           ` Jonathan Wakely
2020-01-07 15:43             ` Jonathan Wakely
2020-01-07 20:44               ` Jason Thorpe
2020-01-10 17:54                 ` Jonathan Wakely
2020-01-14 16:56                   ` Kamil Rytarowski
2020-01-14 21:25                     ` Jason Thorpe
2020-01-16 17:47                       ` Jonathan Wakely
2020-01-16 21:38                         ` Jason Thorpe
2020-01-06 15:34   ` Jonathan Wakely
2020-01-06 23:19     ` Kamil Rytarowski
2020-01-07  0:28       ` Jonathan Wakely [this message]
2020-01-07  0:54         ` Kamil Rytarowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200107002804.GN490107@redhat.com \
    --to=jwakely@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gerald@pfeifer.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=maya@netbsd.org \
    --cc=mjbauer95@gmail.com \
    --cc=n54@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).