Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: strncpy() (was: gets(3) nonsense)
Summary: You just can't win..
Message-ID: <8914@smoke.BRL.MIL>
Date: 18 Nov 88 02:39:10 GMT
References: <867@cernvax.UUCP> <645@quintus.UUCP> <339@igor.Rational.COM> <14447@mimsy.UUCP> <1643@solo11.cs.vu.nl> <434@auspex.UUCP> <1657@solo11.cs.vu.nl> <453@auspex.UUCP> <1666@solo10.cs.vu.nl>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 11

In article <1666@solo10.cs.vu.nl> maart@cs.vu.nl (Litmaath Maarten) writes:
>If you want to copy part of a string into a buffer, do you complain you can't
>give a count to strcpy()? Or do you say: hey, strcpy() doesn't do what I want,
>let's use another function (which happens to be strncpy())?

Except strncpy() has its own problems when the limit is reached,
just as someone observed that fgets() does!

The important idea is that one must think HARD about the implications
of the specifications for library functions, in order to use them
safely in robust, secure code.  There is no easy road to rightness.