Where is strnlen() ?

[Thordur Ivar B.]

On Fri, 13 Aug 2004 02:15:19 +0300
Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:

> On 2004-08-11 20:38, "Thordur Ivar B." <thib at mi.is> wrote:
> > On Wed, 11 Aug 2004 13:03:23 -0700 Kris Kennaway <kris at 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