Beware of strncpy and strncat

Re:Beware of strncpy and strncat by DSMan195276 on Wednesday June 06, 2018 @01:04PM (#17248881)

Especially since `strncpy` takes a `size_t`, meaning that `buflen - 1` will turn from `-1` to `SIZE_MAX` due to the signed to unsigned conversion. I think OP just slightly misremembered what is on the man page:

    strncpy(buf, str, n);
    if (n > 0)
        buf[n - 1]= '\0';

Which still checks `n` after calling `strncpy`, like you mentioned, but doesn't have the underflow problem.

[ Parent | on HN ]

Re:Beware of strncpy and strncat by veli_joza on Wednesday June 06, 2018 @01:22PM (#17249069)

If my count is good, this is correction of correction of correction of original article's correction. And average developer is expected to get it right the first time? It's a miracle anything built in C actually works.

[ Parent | on HN ]

Re:Beware of strncpy and strncat by orwin on Wednesday June 06, 2018 @05:24PM (#17251250)

Yes. An average developper with knowledge in C will. Honestly, around my 3rd year i created a lib containing a struct for strings (well, two, and a couple functions working with them) and i don't think i ever used an strX function again.

I was pretty proud of the "string for already allocated buffer" part of this lib tbh.

Anyway, i'll never take C for a four-hour coding challenge, but for bigger, non-web project, C is really awesome, thank to BLAS and to the fact that most languages implement mostly painless C ffi.

[ Parent | on HN ]

Re:Beware of strncpy and strncat by DSMan195276 on Wednesday June 06, 2018 @11:41PM (#17253073)

I would add that while I do normally use regular C strings rather then my own library, I still can't remember the last time I used any of the random `str*` functions. I don't do much string composition anyway, but the little I do is almost always using `snprintf` or variants (Which have a non-braindead API, unlike `strncpy`). Tons easier to read and much more effective then a bunch of `strcpy`, `strcat` and such.

The only thing I wish the standard library would have is an `asprintf` which would return an allocated buffer. I've written my own, but the easy version utilizing regular `sprintf` requires calling `sprintf` twice (Once to get the length, and once to actually put the string in the allocated buffer). A regular supported version would be much more efficient.

[ Parent | on HN ]

Re:Beware of strncpy and strncat by jwilk on Wednesday June 06, 2018 @06:55PM (#17251817)

dig1 remembered it right. This bug was introduced in man-pages 3.62:

https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/...

[ Parent | on HN ]

Re:Beware of strncpy and strncat by DSMan195276 on Wednesday June 06, 2018 @10:36PM (#17252822)

Huh, well that's embarrassing. It looks like it's still in there too. I googled the man page but I guess I saw an older version. I might submit a patch if I find time. It should really be something like this:

    if (n > 0) {
        strncpy(buf, str, n - 1);
        buf[n - 1] = '\0';
    }

Of course, the error isn't super huge considering if you're using a zero-length buffer as a null-terminated string you're going to have other problems. But they still do check for 0, so IMO it's worth correcting.

[ Parent | on HN ]

Re:Beware of strncpy and strncat by jwilk on Thursday June 07, 2018 @05:06AM (#17254376)

Matthew Kilgore submitted patch to fix this:

https://marc.info/?l=linux-man&m=152834469929748

[ Parent | on HN ]

Re:Beware of strncpy and strncat by dig1 on Thursday June 07, 2018 @08:54AM (#17255322)

Huh, I blindly pasted example assuming man pages are always right. Double check next time :D

[ Parent | on HN ]

Re:Beware of strncpy and strncat by DSMan195276 on Thursday June 07, 2018 @08:58AM (#17255340)

Yes, that would be me :)

[ Parent | on HN ]