Date: Mon, 19 Oct 2009 08:58:05 -0500 From: David Kelly <dkelly@hiwaay.net> To: FreeBSD-Questions@FreeBSD.org Subject: Re: need C help, passing char buffer[] by-value.... Message-ID: <20091019135805.GA35875@Grumpy.DynDNS.org> In-Reply-To: <20091019054344.bb4822ca.freebsd@edvax.de> References: <20091019013337.GA9522@thought.org> <72213BBF-5E05-430D-BF9A-FCD2666951C6@hiwaay.net> <20091019054344.bb4822ca.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 19, 2009 at 05:43:44AM +0200, Polytropon wrote: > On Sun, 18 Oct 2009 22:23:43 -0500, David Kelly <dkelly@hiwaay.net> wrote: > > When not using a count to indicate how much data is in a char* you > > should always test for null. Testing for null is not a sure fire way > > to prevent buffer over runs but its better than nothing. > > There are means like > > #include <assert.h> > ... > assert(s); > > to make sure s is not NULL, or testing for it explicitely like > > if(!s) > ... error handling here ... You are missing my point that *s == 0 is not a good out of bounds range check. > is possible. Furthermore, it is a proven way to give a length > argument along with the (char *) argument, such as the "new" > l-functions for strings, e. g. strlcat() and strlcpy(), do. > > char *skiptags(char *s, int l); > > You can even double-check for l begin != 0. Or you employ a > test with strlen() function-internally. strlen() knows nothing about the buffer allocation. As I originally said, testing for null (and my example tested) is not foolproof but its better than nothing. One should *also* test for the known end of the allocated buffer. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091019135805.GA35875>