From owner-freebsd-hackers  Sun Aug 10 07:54:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id HAA24151
          for hackers-outgoing; Sun, 10 Aug 1997 07:54:06 -0700 (PDT)
Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA24137
          for <hackers@FreeBSD.ORG>; Sun, 10 Aug 1997 07:54:03 -0700 (PDT)
Received: (from karpen@localhost)
	by ocean.campus.luth.se (8.8.5/8.8.5) id RAA12760;
	Sun, 10 Aug 1997 17:05:55 +0200 (CEST)
From: Mikael Karpberg <karpen@ocean.campus.luth.se>
Message-Id: <199708101505.RAA12760@ocean.campus.luth.se>
Subject: Re: creating man 9f
In-Reply-To: <199708101321.GAA20590@hub.freebsd.org> from Darren Reed at "Aug 10, 97 11:07:54 pm"
To: avalon@coombs.anu.edu.au (Darren Reed)
Date: Sun, 10 Aug 1997 17:05:55 +0200 (CEST)
Cc: hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

According to Darren Reed:
> 
> I'd like to nominate the following man pages for duplication into section
> 9f (kernel functions):
> 
> bcmp, bcopy, bzero
> memcpy
> printf, vprintf (I'me sure there are some differences)
> putc
> free
> index, rindex
> inet_ntoa
> qsort
> random, srandom
> strcat (need to remove strncat or add it to the kernel*)
> strcmp, strncmp
> strcpy, strncpy
> strlen
> 
> ...just to start the man9 section off.  Comments ?
> 
> * - there's a noticable lack of the *nprintf functions from the kernel.
>     Given the number of buffer overflow problems and the trend towards their
>     use, shouldn't things like strncat & friends be put in the kernel too ?

Not really realted, but it's always annoyed me that all the strcat and strcpy
functions are so ineffective. They return a pointer to the buffer you
supply to the function (which is useless since you have it already) and
not a pointer to the trailing NUL. So if you want to add two strings you
use strcat twice, and thereby have the whole string walked through at least
too times too much. This always leads to me writing my own "xstrcpy()" or so,
which makes it possible to do:

ptr = xstrcpy(buffer, "first ");
ptr = xstrcpy(ptr,    "second");
ptr = xstrcpy(ptr,    "third");
..etc..

And having it an inline function you basically waste no CPU for meaningless
functioncalls and looping through something you've already looped through.

My point is... shouldn't the kernel, at least, be written with efficiency
in mind? No matter if it's not that big of a deal (I guess the kernel is not
doing too much string handling, anyway). But I guess this is not the only
case of inefficient code.

   /Mikael - mainly blowing off steam for RL stuff :-)