[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: |
Bruno Haible |
Subject: |
Re: [Bug-gnulib] gnulib README patch for size_t addition overflow |
Date: |
Wed, 19 Nov 2003 17:08:16 +0100 |
User-agent: |
KMail/1.5 |
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