Hi Lukas, good points! I use these routines for ages and they definitively deserve the suggested updates.
Thanks! Jirka On Tue, Jan 12, 2016 at 8:02 PM, Odzioba, Lukasz <lukasz.odzi...@intel.com> wrote: > Hi Jirka, > > It should be safe to do free(NULL) so last function can be shortened to > only 2 lines. > > IIRC *alloc fuctions should not set errno on error to anything else than > ENOMEM so you could get rid of errno references in your wrappers. > > Removing else before return p; statement should take care of the warning, > so you don’t need return NULL then. > > > > Thanks, > > Lukas > > > > *From:* hwloc-devel [mailto:hwloc-devel-boun...@open-mpi.org] *On Behalf > Of *Jirka Hladky > *Sent:* Tuesday, January 12, 2016 3:01 PM > *To:* Hardware locality development list > > *Subject:* Re: [hwloc-devel] Static analysis > > > > Hi Brice, > > > > I use following custom routines to check for malloc related errors. > > > > Just my 2 cents. > > > > Jirka > > > > void *util_Malloc (size_t size) > > { > > void *p; > > errno = 0; > > p = malloc (size); > > if (p == NULL) { > > fprintf (stdout, "\nmalloc failed: %s\n\n", strerror (errno)); > > exit (EXIT_FAILURE); > > return NULL; /* to eliminate a warning from the compiler */ > > } else > > return p; > > } > > > > void *util_Calloc (size_t count, size_t esize) > > { > > void *p; > > errno = 0; > > p = calloc (count, esize); > > if (p == NULL) { > > fprintf (stdout, "\ncalloc failed: %s\n\n", strerror (errno)); > > exit (EXIT_FAILURE); > > return NULL; /* to eliminate a warning from the compiler */ > > } else > > return p; > > } > > > > void *util_Realloc (void *ptr, size_t size) > > { > > void *p; > > errno = 0; > > p = realloc (ptr, size); > > if ((p == NULL) && (size != 0)) { > > fprintf (stdout, "\nrealloc failed: %s\n\n", strerror (errno)); > > exit (EXIT_FAILURE); > > return ptr; /* to eliminate a warning from the compiler */ > > } else > > return p; > > > > } > > > > void *util_Free (void *p) > > { > > if (p == NULL) > > return NULL; > > free (p); > > return NULL; > > } > > > > > > > > > > > > On Tue, Jan 12, 2016 at 2:26 PM, Odzioba, Lukasz <lukasz.odzi...@intel.com> > wrote: > > Hi, > I use klocwork, which doesn't mean it is better it just reports different > subset of potential errors. > > Ignoring malloc errors is your design decision, I don't mind it. > From debugging perspective it makes it easier to track it down since you > have null ptr dereference somewhere near malloc . > Malloc might start failing as well as just fail once in process live (i.e. > some other process requested free memory for a short period of time), if an > app is able to survive it's nice if not then well we have to live with that. > > Thanks, > Lukas > > > > -----Original Message----- > From: hwloc-devel [mailto:hwloc-devel-boun...@open-mpi.org] On Behalf Of > Brice Goglin > Sent: Tuesday, January 12, 2016 12:57 PM > To: hwloc-de...@open-mpi.org > Subject: Re: [hwloc-devel] Static analysis > > Hello > > We're running coverity every night and I try to address most of what it > reports (except the netloc/ directory git master which still needs a lot > of work). What tool do you use? > > It's true we don't check malloc() return values in many cases (hopefully > only the small allocations), mostly because we're lazy (and also because > many other things would go wrong when malloc starts failing :/) > > Brice > > > > Le 12/01/2016 12:23, Odzioba, Lukasz a écrit : > > Hi, > > Static analysis tool we use has found quite a lot of potential issues in > hwloc. > > Most of them are type of "NULL ptr dereference" i.e. when pointer is not > checked for null after allocation, but there are some more interesting > cases as well. > > My team distributes hwloc as a part of software package and we could > just ignore those, but I wanted to let you know in case you are interested > in fixing some or all of them. > > > > Please let me know If you would like to get a full list, so I'll prepare > it. > > > > Thanks, > > Lukas > > > > _______________________________________________ > > hwloc-devel mailing list > > hwloc-de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel > > Link to this post: > http://www.open-mpi.org/community/lists/hwloc-devel/2016/01/4698.php > > _______________________________________________ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel > Link to this post: > http://www.open-mpi.org/community/lists/hwloc-devel/2016/01/4699.php > _______________________________________________ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel > > Link to this post: > http://www.open-mpi.org/community/lists/hwloc-devel/2016/01/4700.php > > > > _______________________________________________ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel > Link to this post: > http://www.open-mpi.org/community/lists/hwloc-devel/2016/01/4702.php >
