Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3E1D3A04.ACF0CFE1@phekda.freeserve.co.uk>
Date:	Thu, 09 Jan 2003 08:59:48 +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: RESEND: strlcat, strlcpy [PATCH]
References:	<F9cwAQq12LRF58tP9DL000250b7 AT hotmail DOT com>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

David F wrote:
> There are a couple of omissions in the original paper. The specifications
> for both strlcpy and strlcat fail to consider the case where the buffers
> overlap. IMO, this is a minor issue. I figure most people would assume they
> handle such cases the same as strcpy and strcat, which is to say they don't
> handle such cases. So something along the lines of the following sentence
> should be added to their specification: "If copying takes place between
> objects that overlap, the behavior is undefined." Were they to be
> implemented in C99, their pointer arguments would most likely be restrict
> qualified.

Thanks, I'll add that to the documentation.
 
> The second omission concerns an unconsidered case with regard to the input
> to strlcat. The original paper fails to consider the case when a NUL
> character is not found within the destination buffer. This case is strange
> to say the least and almost certainly represents a bug in the calling code,
> however, I think the behavior of strlcat in such a case should be defined.
> Particularly, I think strlcat should not read past the end of the buffer. I
> believe that in such cases the buffer should remain unmodified and strlcat's
> return value should be the sum of the specified buffer length and the length
> of the would-be concatenated string.
[snip]
> It's worth noting that the implementation proposed for inclusion in djgpp's
> libc will read past the end of the buffer.

Thanks for spotting that. I'll fix that.
 
> Personally, I like the below-included implementations. I believe them to be
> correct, they have no dependencies, and I think any modern compiler should
> be able to generate reasonably decent code from them (I could be wrong
> though; on any or all counts). Inclusion in a libc (and one that will only
> be compiled with gcc, at that) was not one of my goals when I wrote them,
> however.

Thanks.

I always find it hard to work out what's going on with for loops that do
character-by-character copies. That's why I wrote the implementation I
proposed using memcpy, etc. So I prefer my implementation. ;) But I'm not that
attached to it. We can re-use my docs and test program.
 
> DJGPP was one of my first introductions to Free Software, and I am grateful
> for the effort you guys put into it.

Me too.

> I hereby disclaim any copyright interest in the following code.
[snip]

I think you will need to sign and return copyright disclaimers for you and
your employer to DJ. (Sometimes writing code is the easy part.)

Thanks, bye, Rich =]

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

- Raw text -