This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] nuke CONST_PTR

Hi Michael,

ms> Your reasoning seems good, but your testing doesn't.
ms> Seems to me you need to test this when building with Microsoft C.

I think I already addressed this point:

mec> However, in gdb 4.18, gdb 5.0, gdb 5.1, and gdb 5.1, c-lang.c has also
mec> contained this line:
mec>   struct type **const (cplus_builtin_types[]) =
mec> So this form has been in gdb source code for four releases already
mec> without drawing complaint.

Also, the CONST_PTR macro has been unconditionally "struct type **const"
since 5.1, which admittedly is not much time.

ms> OTOH, do we ever build with Microsoft C any more?
ms> Is there any reason to support it?  Cygwin and Djgcc
ms> are both self-hosting, aren't they?

I don't know about Microsoft C.  I do know that I build Cygwin gdb
using Cygwin gcc.  I don't know about djgpp.

ms> So the discussion (if there still is one) is (I think)
ms> "do we still support building with Microsoft C?"

I don't know.

The second half of the question is "and does Microsoft C still have
a problem with struct type **const".

If we do support building with Microsoft C, and if Microsoft C has
a problem with "struct type **const", then gdb 4.18, 5.0, 5.1, and
5.1.1 are all broken in one spot.  Maybe that is not a good reason for
breaking it in other spots.  But one instance of "struct type **const"
has been in released versions of gdb for 34 months now and I don't see
complaints coming in.

Michael C

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]