Re: bfd: use less memory in string merging

[Michael Matz <matz@suse.de>]

Hey,

On Thu, 9 Nov 2023, Jan Beulich wrote:

> >> I think it would be nice to be independent of such an implementation 
> >> detail of the underlying library.
> > 
> > Yes.  But do you mean it as pre-requisite for the patch?  In that case 
> > I'll try something about a bucket allocator for the offsetmap blocks, 
> > though I think it's a bit on the extreme to work around lousy mallocs in 
> > current times.
> 
> I definitely wouldn't go as far as asking for such a rework. What I'd
> like to see though is that the realloc() return values be latched into
> a local, and instead of failing upon the function returning NULL the
> old pointers in the struct simply not be updated. Preferably with that
> adjustment okay to put in.

Oh, that makes sense, yes.  (The contract on the bfd_realloc wrapper is a 
bit unhelpful here, it invariably will set bfd_error_no_memory when 
returning NULL, but I still agree with you that it's nicer to not 
overwrite the existing pointer when realloc didn't work).


Ciao,
Michael.

> 
> Jan
> 
> >> (It may also be worthwhile then to shrink the larger of the
> >> two arrays first. Otoh the comment ahead of mapofs_type already
> >> indicates that this type may need widening at some point.)
> > 
> > That is true nevertheless, so consider this changed in the patch.
> > 
> > 
> > Ciao,
> > Michael.
>