Date: Sat, 11 Jan 2003 12:09:50 +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: <2110-Sat11Jan2003120949+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: <200301102322.h0ANMfu27001@brother.ludd.luth.se>
	(lnobody AT delorie DOT com)
Subject: Re: strlcat, strlcpy, revision 2 [PATCH]
References:  <200301102322 DOT h0ANMfu27001 AT brother DOT ludd DOT luth DOT se>
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

> From: lnobody AT delorie DOT com
> Date: Sat, 11 Jan 2003 00:22:41 +0100 (MET)
> > 
> > What does this mean, exactly?  The specific implementation we have is
> > deterministic, right?  So it is possible to tell exactly what does it
> 
> Probably. I think he's talkning about C standard undefined behaviour.

I don't like citing undefined behavior in documentation that covers
specific implementations.  A specific implementation has specific,
defined behavior, and IMHO we should tell the programmer what that is.

> That's a good idea. But might not say much ("if they do, your code
> might do anything; at least one of the effects being writing over
> memory way out of bounds").

Is this really what will happen?  I always thought strcpy and friends
handled overlapping buffers correctly.  If that's not true, similar
remarks should be added to the docs of strcpy and strcat.