Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!motown!mergvax!inthap!polyof!john
From: john@polyof.UUCP ( John Buck )
Newsgroups: comp.os.minix
Subject: Re: Bug in library routine strncpy(), getenv()
Message-ID: <241@polyof.UUCP>
Date: Thu, 14-May-87 13:41:56 EDT
Article-I.D.: polyof.241
Posted: Thu May 14 13:41:56 1987
Date-Received: Sat, 16-May-87 20:52:46 EDT
References: <3860@cae780.TEK.COM>
Organization: Polytechnic Inst. of NY, Farmingdale NY
Lines: 37
Keywords: malfunction, strncpy, getenv
Summary: strncpy, not malfunction, getenv() probably not broken either

In article <3860@cae780.TEK.COM>, hubble@cae780.TEK.COM (Larry Hubble) writes:
> ...  I believe there is also a bug in the
> library routine strncpy -- it doesn't null terminate the string if the string
> to copy is really longer that "n" characters.  I have not verified or fixed
> this yet, but will post it when I get a chance to cure it.
> 

From STRING(3C)---
	"strncpy(s1, s2, n)
	char *s1, *s2;
	int n;

	Strncpy copies exactly n characters, truncating s2 or adding null
characters to s1 if necessary.  The result will not be null-terminated
if the length of s2 is n or more."

I.E. There is no bug with strncpy().

> The library routine getenv() has a bug in it.  If the environment variable you
> are requesting does not happen to be the first one in the environment table,
> getenv() goes into an infinite loop.
> 
> The fix is very simple.  The first executable line is:
> 
>      while ((p = *v) != NULL) {
> 
> It should be:
>     
>     while ((p = *v++) != NULL) {
> 
All the versions of getenv() I looked at (4.2bsd, system 5, system 3,
Version 7) did not have the indicated looping bug.  The pointer "p" was
incremented in the next line of code; apparently the MINIX people broke
this, or the poster did not read the code carefully.

John Buck
polyof!john