This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] nuke CONST_PTR
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Michael Snyder <msnyder at redhat dot com>
- Cc: Michael Elizabeth Chastain <mec at shout dot net>,gdb-patches at sources dot redhat dot com
- Date: Wed, 13 Feb 2002 12:30:34 -0500
- Subject: Re: [RFA] nuke CONST_PTR
- References: <200202131444.g1DEi0e02865@duracef.shout.net> <3C6A8FCD.2D1D@redhat.com>
> In gdb 4.18 and gdb 5.0, CONST_PTR was conditionally defined as nothing
>> if MSC_VER was defined, and "const" otherwise. In gdb 5.1 and gdb 5.1.1,
>> CONST_PTR is always defined to "const". So CONST_PTR has been
>> unconditionally defined for only a few months.
>>
>> However, in gdb 4.18, gdb 5.0, gdb 5.1, and gdb 5.1, c-lang.c has also
>> contained this line:
>>
>> struct type **const (cplus_builtin_types[]) =
>>
>> So this form has been in gdb source code for four releases already
>> without drawing complaint.
>>
>> Testing: I built this on native i686-pc-linux-gnu and ran the test suite.
>>
>> Okay to apply?
>
>
> Your reasoning seems good, but your testing doesn't.
> Seems to me you need to test this when building with Microsoft C.
>
> OTOH, do we ever build with Microsoft C any more?
> Is there any reason to support it? Cygwin and Djgcc
> are both self-hosting, aren't they?
Not since '98! The line:
>> struct type **const (cplus_builtin_types[]) =
was added in '98 so ever since then GDB hasn't been able to build with
the MSC compiler CONST_PTR was working around. As Michael pointed out,
we've had 4 releases since then.
enjoy,
Andrew