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: [RFA] MIPS16 FP manual call/return fixes


On Mon, 14 May 2012, Jan Kratochvil wrote:

> > strictly speaking we can keep the structure flat if 
> > we decide that complicating it is not worth the saving.
> 
> Technically yes but it is more readable to know this field is valid/used only
> with this subclass.  And it is better not just to rely on unstructured
> comments content.  And to give the field name its real meaning ("func_addr")
> and not just a generic name of overload ("related").  A good example of these
> overloaded generic fields without subclassing is main_type which is such as
> mess I still have problems to fully understand it.

 Yes, I can't disagree, common sense applies.

> >  Actually, I relied on the lack of compilation errors so far; it seems 
> > that while we do have -Wall -Werror, we have -Wno-unused as well which 
> > implies -Wno-unused-variable and has defeated my assumptions.  Any 
> > particular reason why we disable this warning?
> 
> Because there are now many such unused-variable cases needing to be fixed,
> there were recent threads about it (see subject /unused/) by Sergio.
> It looks still not all the cases are fixed to enable the warnings.

 Hmm, fair enough, I wonder if we could take -Wno-unused out in the 
maintainer's mode so as to prompt people to fix their bugs?

> > > >  	      b->type = bp_gnu_ifunc_resolver;
> > > 
> > > Empty line before a comment according to GDB Coding Standards.
> > > 
> > > > +	      /* Remember the resolver's address for use by the return
> [...]
> >  I believe this requirement applies to function and variable/type/etc. 
> > definitions only and I haven't seen this style applied inline in many 
> > places (including the original comment above, actually).  Are you sure?
> 
> I find it more readable with the empty line even in this case.
> You are right there are too many of such cases without empty line in GDB.
> Therefore I do not mind, check it in either way.

 I think common sense applies again, I often find these extra empty lines 
disturbing with small comments, but larger ones definitely do need this 
extra space so that they do not obscure actual code.

 Anyway, 48 hours have passed with no further comments, so I have 
committed this change now, as posted.  If anything that was missed by 
chance pops out, then we can address it with a follow-up change.

 Thanks to everybody involved.

  Maciej


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