[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] gnulib README patch for size_t addition overflow
From: |
Paul Eggert |
Subject: |
Re: [Bug-gnulib] gnulib README patch for size_t addition overflow |
Date: |
18 Nov 2003 10:39:29 -0800 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
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.