Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3E1FEA6C.71BB41E7@phekda.freeserve.co.uk>
Date:	Sat, 11 Jan 2003 09:57:00 +0000
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: strlcat, strlcpy, revision 2 [PATCH]
References:	<E18WkK2-00014U-00 AT phekda DOT freeserve DOT co DOT uk> <4634-Fri10Jan2003223842+0200-eliz AT is DOT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > 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?

Our implementation does, but not all do. That's one reason why strlcat was
developed in the first place.
 
> > + 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.

Again, our implementation could be updated to cope with overlapping buffers.
But the original paper and the NetBSD papers I've looked at don't specify
whether strlcat can or should cope with overlapping buffers. I haven't looked
at the {Open,Net}BSD sources.

If our implementation were able to cope with overlapping buffers, I guess we
could add that as a @port-note. But why tell people things like that? They
will take shortcuts. They will write more portable code, if can't make
assumptions about DJGPP's implementation & overlapping buffers.

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -