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 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/ ]