Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFA: unbreak typedefed bitfield
Date: Mon, 21 Dec 2009 10:00:00 -0000	[thread overview]
Message-ID: <hgngp7$qah$2@ger.gmane.org> (raw)
In-Reply-To: <m3iqc4f47q.fsf@fleche.redhat.com>

Tom Tromey wrote:

>>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
> 
> Joel> I have a general feeling that most of the time, the typedef should
> Joel> have never been passed down.  But I haven't spent the time and
> Joel> effort to try to think globally.
> 
> There are definitely cases where we want to preserve the type that the
> user wrote.
> 
> In C, this matters for printing various character types.  E.g., both
> wchar_t and char32_t may be typedefs of int, but we want to print them
> differently if they use different encodings.
> 
> This preservation has to be pervasive, because of things like:
> 
>     print (wchar_t) 32
> 
> This example doesn't work today, but probably should.
> 
> 
> I agree that check_typedef is a problem.
> 
> Perhaps we could approach the check_typedef problem using a semantic
> analyzer to ensure correct use.  There are other idioms in gdb that also
> require careful attention that would benefit from this; cleanups and
> proper use of TRY_CATCH come to mind, but there are probably others.
> 
> Another approach would be to change TYPE_LENGTH to first call
> check_typedef.

It seems to me that TYPE_LENGTH may return different values before and
after check_typedef is called. Is the 'before' value ever or any use?
If no, and as you say above in some cases we need to preserve some properties
of the typedef, why TYPE_LENGTH could not check if the type is typedef, and
if so, return length of the true type?

- Volodya



  reply	other threads:[~2009-12-21 10:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 12:41 Vladimir Prus
2009-12-18 13:06 ` Joel Brobecker
2009-12-18 14:17   ` Daniel Jacobowitz
2009-12-18 14:20     ` Vladimir Prus
2009-12-18 14:24       ` Daniel Jacobowitz
2009-12-21  9:51         ` Vladimir Prus
2009-12-21 13:23           ` Joel Brobecker
2009-12-18 19:55   ` Tom Tromey
2009-12-21 10:00     ` Vladimir Prus [this message]
2009-12-21 17:08       ` Tom Tromey
2009-12-21 17:15         ` Daniel Jacobowitz
2009-12-21 17:18           ` Vladimir Prus
2009-12-21 17:37             ` Joel Brobecker

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='hgngp7$qah$2@ger.gmane.org' \
    --to=vladimir@codesourcery.com \
    --cc=gdb-patches@sources.redhat.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