This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Getting rid of BFD section->_raw_size and section->_cooked_size
- From: Bob Wilson <bwilson at tensilica dot com>
- To: hp at bitrange dot com, binutils at sources dot redhat dot com
- Date: Thu, 23 Oct 2003 10:33:46 -0700
- Subject: Re: Getting rid of BFD section->_raw_size and section->_cooked_size
- Organization: Tensilica, Inc.
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