Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!pyramid!lll-winken!lll-crg.llnl.gov!casey
From: casey@lll-crg.llnl.gov (Casey Leedom)
Newsgroups: comp.bugs.2bsd
Subject: Re: V1.21 (strncat is broken)
Message-ID: <2721@lll-winken.llnl.gov>
Date: 8 Jan 88 04:20:12 GMT
References: <8801062002.AA15696@okeeffe.Berkeley.EDU> <4557@teddy.UUCP>
Sender: usenet@lll-winken.llnl.gov
Reply-To: casey@lll-crg.llnl.gov.UUCP (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 24

In article <4557@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>>Description:
>>	strncat(3) doesn't truncate strings correctly.
>
>Please don't "fix" this "bug".  It is DOCUMENTED to work this way.  If
>the second string is longer than the size "n" supplied, then NO NULL
>TERMINATER is appended.  It is your MISUSE of "strncat" at fault here!

  No, it is a bug.  I'm embarrassed as the writer of the routine to admit it.
The manual page says the following:

     Strcat appends a copy of string s2 to the end of string s1.
     Strncat copies at most n characters.  Both return a pointer
     to the null-terminated result.

Since the original string is already NUL terminated, appending n
characters from s2 to the end of s1 and then NUL terminating the result
can really be thought of as inserting n characters just before the NUL in
s1.  You'll also note that both the C and VAX assembler versions NUL
terminate the result when strlen(s2) > n.  (Though the C version does have
an error in it because it won't handle n==0 and really should stop
copying one character earlier (it copies a character and then has to
stomp on it with a NUL.))

Casey