Re: Option to elide single-bit bitfields when printing structures

[Eli Zaretskii <eliz at delorie dot com>]

> Date: Tue, 27 Feb 2001 00:16:52 -0800
> From: "Zack Weinberg" <zackw@Stanford.EDU>
> > 
> > > > Then IMHO this feature is less helpful than it could be.  See the list
> > > > above: can you really remember all of the flags if they are not shown?
> > > > And if half of them are shown, is it really easy to know which are and
> > > > which aren't?
> > > 
> > > Perhaps you are not familiar with the way these flags get used in gcc.
> > 
> > I thought you were proposing a general-purpose feature, not something 
> > specific to GCC.
> 
> I am proposing a general-purpose feature.  The GCC usage is a specific
> example of why it would be useful.

The question is whether there are other examples of why such a limited
functionality, whereby only single-bit fields which are set can be
easily displated, would be useful.  My experience with debugging
several large applications (which doesn't include debugging GCC) seems
to say NO.  But that's just me.

> > Perhaps it would be better to make the GCC prettyprinter more robust in 
> > the face of such calamities.  After all, GDB doesn't do anything that any 
> > other program cannot do, to avoid crashing when accessing invalid 
> > addresses and corrupted data structures.
> 
> Oh really?  GDB gets a nice EFAULT/EIO error return from ptrace(2)
> when it tries to dereference wild pointers.  The prettyprinter runs in
> inferior context and gets SIGSEGV when it does that.  We'd have to
> trap it and longjmp out.  The complexity cost would be huge.

What's so complex about a longjmp?  Perhaps I'm missing something,
since I never debugged GCC seriously.

Also, on some OSes, there are system calls and library functions to
check whether a given address is valid or not.