From: Stan Shebs <stanshebs@earthlink.net>
To: gdb-patches@sourceware.org
Subject: Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]
Date: Thu, 09 Feb 2012 19:23:00 -0000 [thread overview]
Message-ID: <4F341D1E.3090206@earthlink.net> (raw)
In-Reply-To: <20120209151621.GB3474@adacore.com>
On 2/9/12 7:16 AM, Joel Brobecker wrote:
>> I naively tried first to just use unnamed field which makes everything great:
> Hmmm, true! This flds_bnds union has been bugging me (when debugging)
> pretty much ever since it was introduced.
>
> Personally, I don't know what the obstacles are for switching to C99
> (technical, FSF policy?). For this particular issue, I feel that it
> would not exist if struct main_type was a C++ class. So that could be
> another way out of that annoying union. (thinking aloud)
>
The expected language dialect can be whatever we decide it to be.
There are basically three categories of gotchas:
1) Non-GCC compilers. Although there's not the bootstrapping problem
that GCC itself has, we do want people to use GDB even if it might be
the only piece of GNU software on their systems. We should at least
build with the standard native compiler on our supported systems, but
should feel free to use whatever flags. Did any of the proprietary
workstation compilers totally miss the C99 boat?
2) Older versions of GCC. For C99 this seems unlikely to be an issue
anymore, who has a still-usable GCC that is over 10 years old?
3) Libraries/headers. This is probably the most common way that people
get hosed - their GCC is modern, but library and headers are several
generations older, and possibly lacking C99-required bits.
Stan
next prev parent reply other threads:[~2012-02-09 19:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 9:28 [patch] Fix gdb-gdb.py for flds_bnds copy-pastes Jan Kratochvil
2012-02-09 9:32 ` [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes] Jan Kratochvil
2012-02-09 15:16 ` Joel Brobecker
2012-02-09 15:37 ` Jan Kratochvil
2012-02-09 18:56 ` Eli Zaretskii
2012-02-10 18:05 ` Tom Tromey
2012-02-10 19:01 ` Jan Kratochvil
2012-02-10 19:22 ` Tom Tromey
2012-02-10 19:29 ` Jan Kratochvil
2012-02-12 10:20 ` Mark Kettenis
2012-02-12 19:23 ` Jan Kratochvil
2012-02-09 19:07 ` Alfred M. Szmidt
2012-02-09 19:23 ` Stan Shebs [this message]
2012-02-10 18:07 ` Tom Tromey
2012-02-09 15:12 ` [patch] Fix gdb-gdb.py for flds_bnds copy-pastes Joel Brobecker
2012-02-09 15:15 ` [commit] " Jan Kratochvil
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=4F341D1E.3090206@earthlink.net \
--to=stanshebs@earthlink.net \
--cc=gdb-patches@sourceware.org \
/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