coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: removing coreutils' final strncpy uses


From: Erik Auerswald
Subject: Re: removing coreutils' final strncpy uses
Date: Sun, 15 Jul 2012 19:38:54 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5

Hi Jim,

On 07/15/2012 06:33 PM, Jim Meyering wrote:
Erik Auerswald wrote:
On 07/15/2012 03:57 PM, Jim Meyering wrote:
Remember the strncpy prohibition I added to "make syntax-check"
not too long ago?  I exempted the uses in pinky.c and who.c
because those programs don't really matter and their uses were
not obviously bad.  Plus, I just didn't feel like it.

Well, today I did, so removed them and, along the way, was surprised
to see that while not officially wrong, they were unwarranted:  they
would uselessly zero-pad out to the end of each destination buffer.

 From reading the man pages of strncpy and stpncpy, stpncpy does the
same. From the stpncpy man page on debian/unstable (date 2011-09-28,
from Linux man-pages 3.40):

DESCRIPTION
  The stpncpy() function copies at most n characters from the string
  pointed to by src, including the terminating null byte ('\0'), to the
  array pointed to by dest. Exactly n characters are written at dest.
  If the length strlen(src) is smaller than n, the remaining characters
  in the array pointed to by dest are filled with null bytes ('\0'), If
  the length strlen(src) is greater or equal to n, the string pointed to
  by dest will not be null-terminated.

As written above the copied string may be unterminated after stpncpy
as well as after strncpy. What exactly is won by using stpncpy over
strncpy?
...

I don't see any guarantee that utmp_ent->ut_host is null-terminated.

Disclaimer: I have read the man page found on my system only, I don't
have experience using str[n]cpy. But I was curious about this change
                           ^
I meant st_p_[n]cpy...

and don't see the improvement.

I knew I shouldn't have pushed that without review.

Introducing bugs is definitely not an improvement.
Thanks for spotting that.

Here's a proposed fix:

[...]

Looks good to me.

Erik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]