Date: Fri, 13 Aug 2004 11:18:49 +0000 From: "Thordur Ivar B." <thib@mi.is> To: freebsd-hackers@freebsd.org Cc: keramida@ceid.upatras.gr Subject: Re: Where is strnlen() ? Message-ID: <20040813111849.047fae64.thib@mi.is> In-Reply-To: <20040812231519.GB7173@gothmog.gr> References: <20040811193254.6f0be2c2.thib@mi.is> <20040811200323.GA37059@xor.obsecurity.org> <20040811203832.728c915b.thib@mi.is> <20040812231519.GB7173@gothmog.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Aug 2004 02:15:19 +0300
Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> On 2004-08-11 20:38, "Thordur Ivar B." <thib@mi.is> wrote:
> > On Wed, 11 Aug 2004 13:03:23 -0700 Kris Kennaway <kris@obsecurity.org>
> > wrote:
> > > On Wed, Aug 11, 2004 at 07:32:54PM +0000, Thordur Ivar B. wrote:
> > > > While porting software from a friend wich was developed under Linux, I
> > > > stumbled upon an error: src/socket.c:236: warning: implicit declaration
> > > > of function`strnlen'
> > > >
> > > > Now my programming experience is nothing to brag about but I wonder why
> > > > strnlen is not a part of FreeBSD's libc. [...]
> > >
> > > That's not a standard function outside the Linux world, and it's not
> > > very necessary for security..no matter how you calculate the string
> > > size, you still have to have your brain engaged when you copy it into
> > > the destination buffer.
> >
> > A notable point. Still I would think that strnlen is a pretty neat
> > functions to avoid dumb mistakes (actually malformed code.) But since
> > it is non-standard, I guess I will have to "turn my brain on" ;>
>
> Malformed code that depends on a particular string buffer limit should
> probably use that buffer limit when copying the string too. I mean, if
> you already know what the maximum allowed length of the string is why
> would you want a library call to tell you about it? ;-)
>
> As someone else posted already, this would probably be useful in code
> that includes structures with predefined size limits, i.e.:
>
> struct buf {
> size_t b_len;
> char b_data[BUFLEN];;
> };
>
> But in this case you already know the maximum length of the b_data field
> and there's no need for strnlen() to tell you about it.
>
> The pessimization that results from always copying BUFLEN bytes from
> b_data members instead of the "useful" part of the string buffer is the
> price that the careless programmer has to pay for forgetting to check
> for proper string termination, I guess.
>
> Instead of introducing new non-standard functions let's fix the broken
> programs :)
>
>
I agree but what I was thinking at the time if I'm reciving user input to a
program wich uses strlen I might be vonerable to buffer overflow attacks (But
that has been cleard up) and ofcourse in most cases you know the length of a
string you are using (exept when you are dealing with user input, wich was the
case in my porting effort.) And since I'm a pedant I think that interducing new
non-standard functions is not an option so I think I will have to
"turn-my-brain-on" as I mentioned in a previous post.
Anyways thanks for the replays.
--
As far as the laws of mathematics refer to reality, they are not
certain, and as far as they are certain, they do not refer to reality.
-- Albert Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040813111849.047fae64.thib>