Such great news. He was single handedly impeding the project.

So, does glibc provide strlcat() yet?

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...

* 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.

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

Only if the implementation details (aside from what is dictated by the spec) of strlcpy meets the originality threshold of a copyrightable work, no?

edit: Also depends on the jurisdiction, http://en.wikipedia.org/wiki/Threshold_of_originality#Exampl... - and you don't necessarily have to change your own license, a valid resolution is also to stop distributing versions of your program that incorporate GPL'd code.

If you would care to look at the code, it is obvious that this is one of the simplest ways to build strlcpy (basically a call to strlen and memcpy and some branching), perhaps I should've said linux kernel-style such that readers familiar with it would know it without needing to look. It is trivial to come up with such an implementation.

IANAL, but at what point do you need to change the license of the entire project? 1 line of code, 3 lines, 5 lines, what constitutes using code from another project? If you call memcpy and your parameters are named the same as the parameters in my project for a memcpy call, who gets to declare his license over that line and thus the project, if it so happens that you once looked at my project? The first one who "invented" it?

If they include work derivative of a GPLed work they don't have to change the license. The license just has to be compatible and redistribution has to conform to the requirements of the GPL.

This distinction is important because someone could take the non-GPL part and distribute it separately under the original license.

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

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...

> 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

"aborting is correct: unexpected truncation is always a logic bug"

How does a function knows what a programmer expects... A lot of use for those potentially truncating functions are for display purpose, where truncating is expected and not a logic bug...

A library function potentially exiting is mostly useless.

And as the GP said, for those cases that truncating is expected (or not a problem) then use strncpy_s.

aborting is a terrible, terrible way to signal an error. strlcpy has a return code to report truncation. Discipline around return codes is already required in C. It's not a huge burden to bear (and if you're doing it right there should be lints to detect when checks are missing).

> "Ulrich left Red Hat for Goldman Sachs some time ago. It's part of an ongoing plan to punish bankers for their role in the 2008 financial crisis."

http://www.reddit.com/r/linux/comments/zzhd9/strfry_the_gnu_...

Maybe be was a plant, and ensured attack vectors into linux by controlling and ensuring bugs in libc

> I was unaware that drepper had left redhat (and glibc).

> He's now at Goldman Sachs.

A much better fit for both parties, from a cultural / personality perspective.

It happened several years ago.

He'll fit right in with all the other sociopaths there.