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

[Paul Eggert]

Bruno Haible <address@hidden> writes:

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

If size_t and ptrdiff_t are 64 bits wide, then so long as every single
object is less than 2**63 bytes (to avoid ptrdiff_t problems), we'll
be OK.  In other words, it's OK to use segments, so long as the whole
address space is still flat from the user's point of view.  (Also, not
every non-flat address space will cause problems: only some of them
will.)

> 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'?

The wrapper is a valid implementation of standard ISO C malloc, so I
see no problem in principle with calling it 'malloc'.  It simplifies
our code overall if we continue to use the standard name.  However, if
I haven't convinced you, let me try to think of other alternatives.