[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: 19 Nov 2003 13:09:11 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]