Re: [PATCH] bfd: make _bfd_section_size_insane part of the public API

[Jan Beulich <jbeulich@suse.com>]

On 06.12.2023 17:15, Andrew Burgess wrote:
> If a BFD user is making use of a function like
> bfd_get_section_contents to read a section into a pre-allocated
> buffer, then that BFD user might also want to make use of
> _bfd_section_size_insane prior to allocating the buffer they intend to
> use in order to validate that the buffer size that plan to allocate is
> sane.
> 
> This commit makes _bfd_section_size_insane public, by renaming it to
> bfd_section_size_insane.
> 
> I've updated the existing uses within bfd/, I don't believe this
> function is used outside of bfd/ currently.
> 
> One place that I plan to make use of this function is in
> gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents.
> This change isn't included in this commit, but will come later if/when
> this has been merged into bfd.

Having seen your ping (and no other response), let me share my view:
This function implements a certain policy, internal to the library.
By exposing it, you would make external users dependent upon this
specific policy. What if later we change our view on what's "insane"?
IOW external consumers want to implement their own, independent policy
(if so desired).

Taking your intended usage example, things would be different if e.g.
bfd_get_full_section_contents() itself used this check unconditionally.
Then I could see a desire to have a way of checking up front whether
allocating a buffer makes sense at all. And really I consider it
questionable for bfd_get_full_section_contents(), when asked to
allocate a buffer, to actually enforce such a library-internal policy.
Like with exposing bfd_section_size_insane(), any change to the policy
may affect external users in unexpected ways.

Jan