Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E200DCE.928151D8@phekda.freeserve.co.uk>
Date: Sat, 11 Jan 2003 12:27:58 +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: <200301102322 DOT h0ANMfu27001 AT brother DOT ludd DOT luth DOT se> <2110-Sat11Jan2003120949+0200-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
[snip]
> 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.

OK. But some people may be learning C programming from the DJGPP libc docs. So
I think the page should at least describe the behaviour as specified and then
note any implementation-specific differences. Otherwise developers may expect
their code to work exactly the same way on other platforms.

> > 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.

Their behaviour is undefined with overlaps according to C99.

Bye, Rich =]

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