Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!yale!cmcl2!stealth.acf.nyu.edu!brnstnd From: brnstnd@stealth.acf.nyu.edu Newsgroups: comp.lang.c Subject: Re: strncpy Message-ID: <9683@stealth.acf.nyu.edu> Date: 23 Jan 90 18:22:39 GMT References: <11527@csli.Stanford.EDU> <000003Q@cdis-1.UUCP> <11616@csli.Stanford.EDU> <48314938.f69e@phobos.UUCP> <11864@csli.Stanford.EDU> Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein) Distribution: usa Organization: IR Lines: 22 In article peter@ficc.uu.net (Peter da Silva) writes: > > That's why it is a bastard function - it is designed to work with > > the null-termination convention but does not guarantee closure. > What it does is provide the most generally useful facility. No. > If it always > null-terminated, it couldn't be used for copies into a known fix-sized > buffer. Huh? strncpy(s1,s2,n) should work like the current strncpy(s1,s2,n) followed by s1[n - 1] = '\0' if necessary. That's a copy into a known fixed-size buffer, preserving null termination. > And since you know the length, you can always null-terminate > the string yourself. Since I do, in fact, always null-terminate the string myself, I'd prefer that strncpy do the job for me. ---Dan