From: "Joseph S. Myers" <jsm@polyomino.org.uk>
To: Bernardo Innocenti <bernie@develer.com>
Cc: Andrew Cagney <cagney@gnu.org>,
Daniel Jacobowitz <drow@false.org>,
Ian Lance Taylor <ian@wasabisystems.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
gdb-patches@sources.redhat.com, binutils@sources.redhat.com,
DJ Delorie <dj@redhat.com>
Subject: Re: [top-level] C++-friendly allocators for libiberty
Date: Mon, 28 Jun 2004 18:52:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.58.0406281842010.1810@digraph.polyomino.org.uk> (raw)
In-Reply-To: <40E06174.9020203@develer.com>
On Mon, 28 Jun 2004, Bernardo Innocenti wrote:
> Andrew Cagney wrote:
> >>Andrew Cagney wrote:
> >>Hmmm... What's the advantage of using XZALLOC over XCALLOC?
> >
> > It avoids that extra argument (but yes, XZALLOC should be implemented
> > using XCALLOC).
>
> Yes, I've always hated the few C library functions with size/number
> of elements pair, as if the caller couldn't do multiplications.
> (fread() and fwrite() come to mind.)
While I generally agree with this view of such functions (fread and fwrite
are worse than calloc, as if the item size isn't 1 you cannot use them
reliably in the presence of possible interrupts by signals), they do at
least if properly implemented check for integer overflow in the
multiplication. See glibc's calloc for how to avoid a division in most
cases in this check, and gnulib's xalloc.h for optimizing the case where
the element size is a constant.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
next prev parent reply other threads:[~2004-06-28 18:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-26 0:50 Bernardo Innocenti
2004-06-26 1:05 ` Bernardo Innocenti
2004-06-26 1:14 ` Ian Lance Taylor
2004-06-26 1:27 ` Bernardo Innocenti
2004-06-26 2:19 ` Ian Lance Taylor
2004-06-26 2:39 ` Bernardo Innocenti
2004-06-26 2:46 ` Daniel Jacobowitz
2004-06-26 3:04 ` Bernardo Innocenti
2004-06-26 17:22 ` Andrew Cagney
2004-06-26 17:37 ` Daniel Jacobowitz
2004-06-26 17:51 ` Andrew Cagney
2004-06-27 5:36 ` Bernardo Innocenti
2004-06-28 15:43 ` Andrew Cagney
2004-06-28 18:27 ` Bernardo Innocenti
2004-06-28 18:52 ` Joseph S. Myers [this message]
2004-07-01 7:18 ` Bernardo Innocenti
2004-06-26 3:45 ` Alexandre Oliva
2004-06-26 4:18 ` Bernardo Innocenti
2004-06-26 18:31 ` Alexandre Oliva
2004-06-27 5:05 ` Bernardo Innocenti
2004-06-26 4:56 ` Zack Weinberg
2004-06-26 11:19 ` Falk Hueffner
2004-06-26 16:52 ` Bernardo Innocenti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0406281842010.1810@digraph.polyomino.org.uk \
--to=jsm@polyomino.org.uk \
--cc=bernie@develer.com \
--cc=binutils@sources.redhat.com \
--cc=cagney@gnu.org \
--cc=dj@redhat.com \
--cc=drow@false.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=ian@wasabisystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox