undefined | Better HN

0 pointsjedisct112y ago0 comments

So, does glibc provide strlcat() yet?

0 comments

6 comments · 2 top-level

shmerl12y ago· 2 in thread

I also wait for strlcpy. In cases when I need it on Linux I just take OpenBSD implementation:

* http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/st...

We use the linux kernel implementation at neovim. But a libc (and possibly asm optimized) implementation would be nice too (it could avoid two runs over the data). Not that it's likely to be a big improvement, strlen and memcpy are usually some of the most optimized functions there are.

justincormack12y ago

In that case you need to change the license of neovim to GPL, as that is the license for Linux kernel code.

3 more replies

quotemstr12y ago· 2 in thread

It shouldn't. strcpy_s is better in every way and is already the standard. See https://lwn.net/Articles/507365/

ggreer12y ago

Actually, there are big problems with strcpy_s and strcat_s. First, strcpy_s abort()s the process if there would have been an overflow, making it useless for most programs. Second, Microsoft already has a function named strcat_s, and it behaves differently than the spec.

Here's VC++'s strcat_s:

    errno_t strcat_s(
        char *strDestination,
        size_t numberOfElements,
        const char *strSource 
    );

In VC++, numberOfElements is the size of strDestination. In the C11 spec, that parameter is the maximum number of bytes to copy into strDestination. People are going to search for strcat_s docs, find the MSDN page, and write buffer overflows.

If strlcpy/strlcat aren't available on a target platform, I stick them them in a util.h/util.c, wrapped in #ifndefs. Like so: https://github.com/ggreer/the_silver_searcher/commit/a43dc87...

quotemstr12y ago

> Actually, there are big problems with strcpy_s and strcat_s. First, strcpy_s abort()s the process if there would have been an overflow, making it useless for most programs

aborting is correct: unexpected truncation is always a logic bug. Truncation can lead to unexpected behavior, so better to fail fast than to get into a state about which you probably haven't reasoned. If you really want strlcpy-like truncation, use strncpy_s (which, unlike strncpy, acts sanely with respect to NUL termination and filling). Of course, on untrusted input copied into a fixed-size buffer, you should be using strncpy_s instead of aborting. Use the right tool for the job.

> In VC++, numberOfElements is the size of strDestination. In the C11 spec, that parameter is the maximum number of bytes to copy into strDestination.

That's not actually a distinction. The purpose of the function is to ensure that the code writes no more than numberOfElements bytes into strDestination. Both versions of the function do that.

Note that the wide character versions of these functions are both specified in number of elements. (So are the narrow character versions, but the difference in moot because sizeof(char) == 1).)

> If strlcpy/strlcat aren't available on a target platform, I stick them them in a util.h/util.c, wrapped in #ifndefs.

Or you can use https://slibc.googlecode.com/svn/api-doc/html/index.html

2 more replies

j / k navigate · click thread line to collapse