This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Dynamic growable arrays for internal use
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Carlos O'Donell <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 1 Jun 2017 11:08:52 -0700
- Subject: Re: [PATCH] Dynamic growable arrays for internal use
- Authentication-results: sourceware.org; auth=none
- References: <edae68d6-998b-58a6-a8df-82703341da23@redhat.com> <ce479249-6362-6a58-ec9b-d6227ef99db9@redhat.com> <f7536497-ab89-28d1-c565-f9a2baf1cffd@cs.ucla.edu> <4ed5035d-3b88-0030-b3b4-b7e4e2e13e88@redhat.com>
On 06/01/2017 09:13 AM, Carlos O'Donell wrote:
http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/xalloc.h
http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/xmalloc.c
Before I look...
What license do these files have?
They're GPLed, with copyright assigned to the FSF. Although we haven't
run into a need for an LGPLed version, that would not be hard to
arrange, so I wouldn't worry about the LGPL-vs-GPL licensing issues.
One other thing: I'm implementing a slightly different version for
Gnulib that uses ptrdiff_t rather than size_t for sizes (and is LGPL
rather than GPL since it will clearly have uses in library situations).
Using ptrdiff_t improves reliability, since one can compile with
-fsanitize=undefined to catch integer overflow with size calculations.
Over the years we have found that using size_t for byte and object
counts leads to problems for which there is no effective automated
checking. This is why I suggest that new memory-allocation APIs use
ptrdiff_t rather than size_t.