Re: [Bug-gnulib] gnulib README patch for size_t addition overflow

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> Paul Eggert wrote:
> > + * If an existing object has size S, and if T is sufficiently small
> > +   (e.g., 8 KiB), then S + T cannot overflow.  Overflow in this case
> > +   would mean that the rest of your program fits into T bytes, which
> > +   can't happen in realistic flat-address-space hosts.
> 
> A specialization of this statement (with S = SIZE_MAX and T = 1) is that
> malloc (SIZE_MAX) is guaranteed to fail. But on 2003-11-01 you said:
> 
> > it assumes that malloc (SIZE_MAX) always fails, which is probably a
> > portable assumption but is a bit worrisome nonetheless.

Yes, it's in the same category.  That is, the S + T proviso above is
probably a portable assumption (with a very high probability :-) but
is a bit worrisome nonetheless.  So, if it's easy to write and
maintain code that works even without that assumption, and is no less
efficient, then I would do so.  However, in practice it's often more
of a pain to write and maintain the code that way, and it can slow
down execution a bit, so there are good arguments for omitting these
redundant checks.


> So is it worrisome or not? Do we need the 'size_overflow_p' checks before
> malloc() or not?

It depends on whether we're worried about porting to hosts without
flat address spaces.  I don't know of any such hosts that are of
current or future interest to the GNU project.  I don't expect such
hosts to be of practical interest during our lifetimes.  If some hosts
like that arise later, our descendants can worry about the issue then
(and they'll have a lot of work to do! this little issue will be a
tiny fraction of the overall work); but in the meantime we have more
important things to do.


> I don't want to redo the size_t checking patches to linebreak.c,
> vasnprintf.c, etc. the day we notice that malloc (SIZE_MAX)
> unexpectedly succeeds on platform XYZ.

As I mentioned earlier, there's a simple fix for that problem: we can
include a malloc wrapper that rejects SIZE_MAX.  This is much simpler
and easier to maintain than including size checks all over the place.
I'd rather use that approach in the code that I help maintain.

I don't think such a wrapper is high priority now, since I don't know
of any practical host that needs it.  If you'd like to have such a
wrapper and think that would simplify the mainline code for
linebreak.c etc., I can volunteer to write it.  However, I vaguely
recall that you don't like the existing wrapper for some reason
(perhaps you thought it should have a different name? sorry, I don't
recall the details) so perhaps you can give advice on what you'd like
to see in this area before I charge in and code anything.