Date: Fri, 10 Jan 2003 22:38:43 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <4634-Fri10Jan2003223842+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <E18WkK2-00014U-00@phekda.freeserve.co.uk>
	(rich AT phekda DOT freeserve DOT co DOT uk)
Subject: Re: strlcat, strlcpy, revision 2 [PATCH]
References:  <E18WkK2-00014U-00 AT phekda DOT freeserve DOT co DOT uk>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Thu, 09 Jan 2003 21:35:54 +0000
> From: "Richard Dawe" <rich AT phekda DOT freeserve DOT co DOT uk>
> 
> Here's revision 2 of my implementation of strlcat & strlcpy
> for DJGPP.

On second thought, I have a couple of comments:

> + @code{strlcat} may be used as a less ambiguous alternative
> + to @code{strncat} (@pxref{strncat}).  Unlike @code{strncat},
> + @code{strlcat} @emph{always} nul-terminates the destination @var{dest}

I might be forgetting something, but IIRC, strncat also always
nul-terminated the result, didn't it?

> + If @var{dest} and @var{src} are overlapping buffers, the behavior
> + is undefined.

What does this mean, exactly?  The specific implementation we have is
deterministic, right?  So it is possible to tell exactly what does it
do when the buffers overlap, right?  If so, I think we should describe
the actual behavior of our implementation.