> > Message: 2 > Date: Thu, 31 Mar 2011 10:11:18 -0600 > From: Lenny Maiorani <[email protected]> > Subject: Re: [cfe-commits] [PATCH] review request: mempcpy() checker > implementation for Static Analyzer > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On 03/30/2011 05:34 PM, Lenny Maiorani wrote: > >> As for the modeling of mempcpy() (and memcpy() for that matter): the > >> >> behavior is that if NULL is passed as either the src or dst there > will > >> >> be a NULL pointer dereference unless the number of bytes to copy is > 0. I > >> >> am re-working the flow through evalCopyCommon to accurately reflect > that. > > > I'm fine with that coming in with a later patch. I just didn't know > what the plan was. Please feel free to use FIXME comments in the code to > indicate "things to do" in the future. > > > > > > If you want to regenerate the patch without tabs (and comments > adjusted), I'll be happy to apply it! > Attached is a revised patch. The tabs and comments are reformatted. > > More importantly, mempcpy() (and memcpy() for that matter) are being > properly modelled. Meaning, if 0 bytes are to be copied it ignores the > inputs. If the number of bytes to be copied is >0 then then the dest and > src inputs are verified to be non-NULL. NULL triggers a bug report. > Otherwise it is ensures that src and dest do not overlap and the dest > buffer is large enough for the incoming bytes and triggers a bug report > if it is not. Finally, it bind the return value (for mempcpy() is the > byte after the last byte copied). > > > -Lenny >
Hello Lenny, regarding the issue of NULL source and destination: we've recently hit a bug at work where memcpy was called as: memcpy(NULL, NULL, 0); and it did crash on a segfault. I asked for enlightenment on StackOverflow and after trudging through the C standard, it appears that there is no special case for the 0 bytes count: http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0/5243068#5243068cites the relevant portions of the standard. So I think you should remove the exception and verify the non-nullity of source and destination in any case. Thanks for this useful check, it would have been very valuable to us :) Matthieu.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
