This is the mail archive of the gdb-patches@sourceware.org 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: [RFC] Initial pass at supporting the Go language


>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Tom> I think this over-exposes some buildsym details to dwarf2read.

Doug> Sigh.
Doug> This is what I get for monkey-see-monkey-do hacking.
Doug> You can't trust any part of gdb to be what the powers-that-be find acceptable.
Doug> [The code in question is far from rare, and any details are certainly
Doug> not protected in a way that imposes or even suggests a proper API.  A
Doug> day I continue to wish for btw.]

I don't insist on changing this.  In fact I thought it was reasonably
clear that I was approaching it as a tradeoff between ugly alternatives.
I grepped the tree looking for similar uses of struct pending, and
didn't find any.

Tom> What is the problem here?

Doug> The choice of what encoding to use is, ultimately, a property of the
Doug> thing you are printing, not any global state.  Plus Go generally uses
Doug> utf8; I wasn't willing to have the Go support change the target
Doug> encoding.

It seems to me that if a Go string is UTF-8, then it is friendliest to
the user to print it as such.  After all, you're already doing other
Go-specific decoding here.

If the user really needs to see the details, he can "set lang c" and see
the underlying representation.

That said, I don't mind either way here, either.  I don't actually know
much about Go.

Tom


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