Home Original page

Getting rid of BFD section->_raw_size and section->_cooked_size

Bob Wilson bwilson@tensilica.com
Thu Oct 23 17:33:00 GMT 2003 
Just a few minor comments....

Hans-Peter Nilsson wrote:
> Alan Modra suggested using a base size and a difference, which seems a
> good idea.

I don't particularly care whether you use (base + diff) or (raw, cooked), and 
more importantly, with an interface such as the one you have proposed, it 
doesn't matter, does it?  I don't think a client using the proposed interface 
can tell the difference between these two representations.  

As far as I can tell, the intended purpose of the "cooked" size is for 
relaxation.  I would prefer some different function names to clarify this, 
using "relax" instead of "alter":

bfd_unrelaxed_section_size
bfd_relax_section_size

Even with that change, I find the name of bfd_relax_section_size confusing.  
Since this function takes the total cooked size as the argument, I would 
expect its name to be more similar to bfd_set_section_size (i.e., with "set" 
in the name).  Likewise, I would find it more natural if 
bfd_relax_section_size took the difference in size as the argument.  I read 
that name with "relax" as a verb and the obvious argument (to me anyway) is 
the amount of relaxation.  I would use the following names:

bfd_set_relaxed_section_size (replacing bfd_alter_section_size)
bfd_relax_section_size (replacing bfd_incr_section_size)

Not that it matters much, but I think you could choose either one of these to 
be implemented as a macro in terms of the other.  I don't know if you 
considered swapping them.  If the underlying representation is (base + diff), 
then it seems like the function ought to be the one that takes the diff as 
the argument.

Unless it happens to fit conveniently into the interface, as it does in your 
original proposal, I don't see the need for the bfd_incr_set_section_size 
macro.  I think I would leave it out.

Those are just my personal preferences.  Even if you ignore them all, I'll be 
glad to see this change.  Thanks for working on cleaning up the interface!

--Bob
More information about the Binutils mailing list