GNU libc 2.15 released

Reasonable programming languages have real character data type.
Reasonable programming languages also have one-dimensional arrays.
This route reasonable programming languages get strings (for free).
They also have automatic OOB access checks.

No part of this strncpy/strlcpy() idiocy makes sense in reasonable programming language universe. They won't even understand what the fuss is all about.

Wow. You just put forward the ONLY reasonable argument in this thread for why strlcpy should not be included in glibc. Congratulations.

However, your argument is flawed, because it assumes that I will not check the return value of strlcpy and act appropriately. Functions have return values for a reason. If I am dealing with UTF8 data, I will not try to truncate the string on an arbitrary byte boundary. I will simply bail out when I'm told the string is too long to fit in my buffer.

The rest of the thread is just a bunch of "advocacy" (read: ignorance). Most it seems to center on people saying "just use std::string, it will fix what ails ye!"

This is good except that,
1. std::string offers the same level support for unicode as char* -- i.e., none.
2. using std::string to blindly copy user-supplied data opens you up to a different kind of security vulnerability, the denial of service.
3. std::string always allocates space on the heap, which makes it unsuitable for many uses
4. a lot of functions in the C++ standard library take char* arguments, so you have to learn how to use char* anyway.

Then there's the people who claim that still other programming languages will magically make the problems of string manipulation go away.

It simply isn't so.

For example, in Python or Java, control characters can be inserted into strings. This means that printing the strings to stdout later could cause undesirable effects to the user. If they are running in an xterm or in a GNU screen session, it could execute arbitrary commands. Will the higher level languages protect you from this? No.

Then there's the problem of normalization. There are four different ways to normalize unicode strings. That means that if your programming language wants to natively support the operation of comparing two strings, it has to have four different kinds of equals sign.

There's no Java worshippers in this thread (strange, we have every other kind of critter) but just to set the record straight, you cannot simply count the number of chars in a string in Java and assume that that is the length. Java uses UCS-2, so this will work only for the basic multilingual plane. There are reasons to use Java, but this isn't one of them.

tl;dr. There are lots of gotchas surrounding using strings in C, but some of them exist in every language. Unicode is complex and understood by few. Simple solutions to complicated problems are usually wrong.

The whole point of strlcpy is that it does a strlen+memcpy at the same time. That's where its name comes from.

Please post sample code that's any shorter, faster OR safer than

if (strlcpy(dest,src,LEN) >= LEN) { return_with_error }

before making such assertions. Thanks.

C as a language does not have exceptions. You can complain all you want that calling strlcpy() and friends without checking its result leaves your data in an inconsistent state, but that's a problem of the language. Any other function that copies a string into a buffer will have the exact same problem.

i assume a certain level of intelligence of LWN readers, but apparently not everyone meets it. not that i had expectations based on your past performance (or rather, lack thereof) in those other security related threads ;).

> So it's acceptable for use of strmcpy to require error checking, but not
> acceptable for use of strlcpy to require error checking. Got it.

too bad i didn't say anything like it :). on the other hand you did say this:

> It is clear that it would make error checking more difficult.

so you're smart enough to understand strl* error checking (ok, i'm assuming it for the sake of discussion ;) but you're too dumb to understand strm* error checking. i think that pretty much establishes your programming knowledge and the value your opinion on security matters carries.

> Nobody said anything about coming up with a substitute for correct code[...]

you did. everyone else promoting strl* did too. i even explained why. you can find it in this very thread, but then i don't know if i should directly link to it, it might confuse you. oh the irony ;).

> Another opinion presented without justification.

actually, i did explain it as well, but linking to it... ok, forget it, it's way beyond your mental capacity.

> snprintf is fast

yeah dude. it smokes str*. /o\

this is the difference between a programmer who writes correct programs and one who doesn't. the biggest issue with strl* is that it cultivates the latter kind. an insecure strcpy is already a sign of a badly designed program, strlcpy won't make that bad design go away either (at worst, it'll introduce new issues due to the all too often omitted truncation checks). and when you fix the design you'll suddenly find yourself without the need for strlcpy.

> I fail to see what's so bad about leaving a truncated string in the
> destination buffer. If you do proper error checking, you'll ignore the
> contents of the destination anyway.

then it was a pointless burn of precious CPU time (remember how strlcpy still has to compute the input's length? read that blog i linked above to see how that scales). it's not exactly the hallmark of properly written programs. a good design simply avoids truncation altogether and limits it only to cases that are somehow dictated by existing API or the problem itself. also it's funny that you talk about error checking and ignoring the truncated content (hello sensitive information leak) whereas right in the next paragraph you hold the same against strcpy_s ;).

> [...]at least [strlcpy] gets the job done.

it gets something done, no doubt. the difference in opinion is whether that something is the right thing or not.