This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH, libgfortran] Add overflow check to xmalloc
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Bernhard Reutner-Fischer <rep dot dot dot nop at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 Jun 2014 09:20:09 +0300
- Subject: Re: [PATCH, libgfortran] Add overflow check to xmalloc
- Authentication-results: sourceware.org; auth=none
- References: <CAO9iq9FrhNHVV2jDPafpq_6MjMGk-v4DgEOZ472c2uV7L2X4Bg at mail dot gmail dot com> <CAO9iq9HpOSSXCHWVFc0t0EQHKea+QVEEEmNYjY9L=7t+kh5o=A at mail dot gmail dot com> <CAO9iq9Epy02hgq4s3nknu+CSXq7RNrQnnDc0AF0wsUgpU49bAQ at mail dot gmail dot com> <CAO9iq9Gqj+9rQhMyUgTdzn+=9befKO-YNxDVQqdd2MHjTQbbBw at mail dot gmail dot com> <CAO9iq9FDj9H3+XGqsjFOXG=Jz70hyTNFbCfP+=U+-MUiSx2SDg at mail dot gmail dot com> <1469dfb0fd8 dot 2763 dot 0f39ed3bcad52ef2c88c90062b7714dc at gmail dot com>
On Sun, Jun 15, 2014 at 8:23 AM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
>
>> >> On Tue, May 20, 2014 at 12:42 AM, Janne Blomqvist
>> >> <blomqvist.janne@gmail.com> wrote:
>> >>> On Thu, May 15, 2014 at 1:00 AM, Janne Blomqvist
>> >>> <blomqvist.janne@gmail.com> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> a common malloc() pattern is "malloc(num_foo * sizeof(foo_t)", that
>> >>>> is, create space for an array of type foo_t with num_foo elements.
>> >>>> There is a slight danger here in that the multiplication can overflow
>> >>>> and wrap around, and then the caller thinks it has a larger array
>> >>>> than
>> >>>> what malloc has actually created. The attached patch changes the
>> >>>> libgfortran xmalloc() function to have an API similar to calloc()
>> >>>> with
>> >>>> two arguments, and the implementation checks for wraparound.
>> >>>
>> >>> Hello,
>> >>>
>> >>> attached is an updated patch which instead introduces a new function,
>> >>> xmallocarray, with the overflow check, and leaves the existing xmalloc
>> >>> as is. Thus avoiding the extra checking in the common case where one
>> >>> of the arguments to xmallocarray would be 1.
>> >>>
>> >>> Tested on x86_64-unknown-linux-gnu, Ok for trunk?
>> >>>
>
>
> I would prefer if xcmalloc would not be named xmallocarray.
Hmm, never heard of that one before, but I have no particular
preference wrt the naming of the function. Ok with that rename?
--
Janne Blomqvist