Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!mips!apple!sun-barr!decwrl!shelby!csli!poser
From: poser@csli.Stanford.EDU (Bill Poser)
Newsgroups: comp.lang.c
Subject: Re: strncpy
Keywords: strncpy null termination
Message-ID: <11510@csli.Stanford.EDU>
Date: 21 Dec 89 21:35:28 GMT
References: <1231@srhqla.SR.COM>
Sender: poser@csli.Stanford.EDU (Bill Poser)
Reply-To: poser@csli.stanford.edu (Bill Poser)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 17


I should clarify that: (a) I know perfectly well HOW strncpy works. My
question concerned the rationale for this design; (b) I know that it is
not hard to produce null-termination and indeed have my own version of
strncpy that does this. But the fact that it isn't hard to produce
null termination doesn't explain why the standard version was designed
the way it was. There is nothing terribly difficult about anything in the
string library.

So far I have heard of one good use for strncpy without null termination.

I have also been told that it is useful for copying into fixed length
char arrays which are not intended to be null-terminated when full.
I am aware of such string representations, but those aren't the standard
C string representation and so the question arises as to why the
standard string library should include a function that doesn't fit the
usual representation of strings.