On Sunday, May 4, 2014, patrick keshishian <sids...@boxsoft.com> wrote:
> On Sun, May 04, 2014 at 12:29:59AM -0700, Philip Guenther wrote:
> > On Sun, May 4, 2014 at 12:21 AM, patrick keshishian
> > <sids...@boxsoft.com<javascript:;>
> >wrote:
> >
> > > On Sun, May 04, 2014 at 02:38:40AM -0400, Jean-Philippe Ouellet wrote:
> > >
> > ...
> >
> > > > - if ((irow = (char **)malloc(sizeof(char *) *
> > > > - (DB_NUMBER + 1))) == NULL) {
> > > > + irow = reallocarray(NULL, DB_NUMBER + 1, sizeof(char
> *));
> > >
> > > why not use calloc(2)?
> > >
> >
> > Please justify your belief that the existing code is wrong by lack of
> > memset/bzero. Please do so for *ALL* the places where you suggested
> using
> > calloc() where Jean-Philippe Ouellet's patch suggest reallocarray().
>
> How did you deduce my "belief" to be such?
The difference between reallocarray(NULL, x, y) and calloc(x, y) is that
the latter zeros the allocated array. Ergo, your suggestion to use calloc()
instead of reallocarray() indicates a belief that the array should be
zeroed, meaning the existing code is wrong.
> The code was changing malloc(n * size) to reallocarray().
> Typical "correction" for this usage has been to convert to
> calloc(2), "in order to avoid possible integer overflows".
> Seeing that "reallocarray() appeared in OpenBSD 5.6", I am
> sure it is an equally fine interface.
Please *support* the use of reallocarray() in code that would otherwise
have to do the overflow check itself (and possibly screw it up) or use
calloc() (and zero possibly large chunks of memory unnecessarily)!
Philip Guenther
