From owner-freebsd-hackers  Tue Sep 19 21:43:42 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA16393
          for hackers-outgoing; Tue, 19 Sep 1995 21:43:42 -0700
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA16386
          for <hackers@FreeBSD.ORG>; Tue, 19 Sep 1995 21:43:40 -0700
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA13737; Tue, 19 Sep 1995 21:40:43 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199509200440.VAA13737@phaeton.artisoft.com>
Subject: Re: Policy on printf format specifiers?
To: peter@taronga.com (Peter da Silva)
Date: Tue, 19 Sep 1995 21:40:42 -0700 (MST)
Cc: terry@lambert.org, peter@taronga.com, hackers@FreeBSD.ORG
In-Reply-To: <199509200120.UAA13405@bonkers.taronga.com> from "Peter da Silva" at Sep 19, 95 08:20:33 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1083      
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> > If you consider reducing the MAXPATHNAME by one for every expansion,
> > then yes, I suppose it does.
> 
> Why does NAMEI need to expand anything?

Symbolic links replacing path components that are not the terminal
path component get expanded into the cn_pnbuf in the nameidata
structure.  This reduces the effective MAXPATHLEN.

Symbolic links replacing termial path components when FOLLOW is set
replace the cn_pnbuf in the nameidata structure.  This does not
reduce the effecive MAXPATHLEN.

This is because symbolic links are not resolved by calling namei on
them in place in the link read buffer (going recursive in namei).

This is functionally equivalent to coroutine recursion in FORTRAN,
though one does not need to expand local variables into arrays to
get a "stack".  The storage is the cn_pnbuf, MAXPATHLEN bytes in
length.

It may be an intentional hack to save kernel stack space.

Or it might just be bogus.

But it's there.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.