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

[Bruno Haible]

Paul Eggert wrote:
> 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

The experience I've just made with vasnprintf.c is that is more maintainable
to put xsum and xtimes everywhere where a size_t value is constructed
that may be bigger than all previously seen ones, than to think about
optimizing away half of them. It's preferrable to write

     length = xsum (length, 1);

than

     length++;

because someday the increment '1' might be replaced by 'precision' or
'width' or some other entity that is bigger than a fixed small amount.

> 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.

You know that Linux/IA-64 internally uses a segmented architecture?
Each segment is 2^60 bytes.

> 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)

Yes my main objection is the name: any thing that's called 'malloc'
in the source code should behave like the standard ISO C malloc.
'xmalloc' is already taken, maybe call it 'xsize_malloc'?

Bruno