From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Andrew Cagney Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] gdb extension for Harvard architectures Date: Wed, 03 Oct 2001 14:33:00 -0000 Message-id: References: <3BB4D843.A92818B9@cygnus.com> <3BB512A9.6050801@cygnus.com> <3BB5195F.6050603@cygnus.com> <3BBB50C0.BD01BF20@cygnus.com> <3BBB5391.4010001@cygnus.com> X-SW-Source: 2001-10/msg00065.html Andrew Cagney writes: > Without change. My contention is that the user is almost never going to > want to do what you just described. Why make what the user is going to > want to do hard? Michael's change makes what the user wants possible at all, which is an improvement over the current situation. You are asking for an additional improvement, which can be discussed separately from Michael's change. But to answer the question anyway: Sometimes it is better to leave what the user usually wants to do somewhat hard, because making that specific case easy makes a lot of other stuff even weirder. You're essentially proposing: - that a cast expression like (T) EXPR would not result in a value of type T, but some other type chosen to save the user's keystrokes, and - that we make GDB evaluate expressions like `(int *) &main' differently from the way the compiler does. Those set off warning bells, for me. You can special-case this stuff to make the naive user's behavior do the right thing want all you want. If you've ever had Microsoft Word correct your capitalization or automatically munge your paragraph formatting, you know what the resulting systems feel like to use. In contrast, once you do explain to someone how to do what they want under Michael's and my proposal, it makes sense, given the architecture. You can then correctly predict how a half-dozen other weird things would be done. All the rules you already know about types apply naturally to the extension. As I see it, these architectures have a discontinuity that we're simply not accustomed to, though people in older times wouldn't have been so surprised. And we've provided a way to accurately describe that sort of discontinuity; using our system, things "just work" that can't be made to work without our system.