From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 13 11:18:59 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CAE116A4CE for ; Fri, 13 Aug 2004 11:18:59 +0000 (GMT) Received: from smtp.mi.is (smtp.mi.is [217.151.180.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0D2143D3F for ; Fri, 13 Aug 2004 11:18:58 +0000 (GMT) (envelope-from thib@mi.is) Received: from caulfield.bitcode.org (bofh.bitcode.org [217.151.165.254]) by smtp.mi.is (8.12.10/8.12.10/1.0.1) with SMTP id i7DBIniv021675; Fri, 13 Aug 2004 11:18:49 GMT Date: Fri, 13 Aug 2004 11:18:49 +0000 From: "Thordur Ivar B." To: freebsd-hackers@freebsd.org 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> Organization: n/a X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: keramida@ceid.upatras.gr Subject: Re: Where is strnlen() ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2004 11:18:59 -0000 On Fri, 13 Aug 2004 02:15:19 +0300 Giorgos Keramidas wrote: > On 2004-08-11 20:38, "Thordur Ivar B." wrote: > > On Wed, 11 Aug 2004 13:03:23 -0700 Kris Kennaway > > 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