Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Specifically, why does libc have strncpy(), which is far worse than strlcpy() in every possible way (useless return value, non-NUL terminated destination string)?
Still no strlcpy and friends
Posted Mar 23, 2012 8:14 UTC (Fri) by PaXTeam (subscriber, #24616)
for wahern (since i'm lazy to split the post ;): count the number of strl* usages in the OpenBSD base system and then count the usages where the return value is checked and acted upon (and for added bonus, figure out which of the rest introduces a bug due to the silent truncation). that's why it's a conceptually broken interface if even its own promoters don't do it right.
Posted Mar 23, 2012 20:21 UTC (Fri) by cmccabe (guest, #60281)
Recent, maybe. Thorough-- nope. Among other things, the author suggests replacing strlcpy with a new function of his own design, which returns the length of the target string rather than the length of the source string. It's not clear that programmers would find this an easier to use API. It is clear that it would make error checking more difficult. No thanks.
> Note that i didn't say that the commonly used alternatives (e.g., strn*)
> were that much better, it's just that strl* are *not* the proper
> solution either.
This is the crux of the issue. People are trying to make the situation better and you are getting in the way with "but it doesn't meet my criterion for absolute perfection." It's not even clear that *any* C string manipulation function could meet your amorphous, unspoken criterion.
Meanwhile, the rest of us just emulate strlcpy with snprintf.
Posted Mar 24, 2012 13:58 UTC (Sat) by PaXTeam (subscriber, #24616)
second, i never said anything about 'absolute perfection', although now that you brought it up, yes, i believe that there's no substitute for correct code. the problem is that strl* doesn't let you easily write it. however it does easily let you produce silent truncation as you can see it in the OpenBSD base system itself. for correct code you have to know your string sizes and adjust your buffer sizes accordingly, simple as that.
third, i very much hope the snprintf comment was just a silly programmer's joke. otherwise please stop writing code.
Posted Mar 24, 2012 16:23 UTC (Sat) by tjc (subscriber, #137)
Perhaps an a well-reasoned explanation as to why you think its bad would persuade me otherwise...
Posted Mar 24, 2012 18:16 UTC (Sat) by PaXTeam (subscriber, #24616)
Posted Mar 28, 2012 18:39 UTC (Wed) by cmccabe (guest, #60281)
Well, do you agree with his conclusions or not? If so, you should be telling the world about the virtues of strmcpy and strmcat. If not, then you shouldn't be linking to his post as an explanation. If you agree with some of his analysis but disagree with other parts (including the conclusion), what's the point of linking to it? It seems like you are just creating confusion. Maybe you are confused yourself.
> (speaking of which, if you're unable to understand error
> checking with strm* then you're quite hopeless as a programmer anyway, no
> amount of str* functions will save you).
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.
> second, i never said anything about 'absolute perfection', although
> now that you brought it up, yes, i believe that there's no
> substitute for correct code
This is more "yes, but also no" out of you. Nobody said anything about coming up with a substitute for correct code. I like correct code too, just like fluffy bunnies, motherhood, and apple pie. Where we are disagreeing is in what C interfaces tend to produce that code.
Any interface that copies a string into a fixed buffer has to have one of two failure modes: truncation or refusal to write anything. There are other failure modes, like strncpy's insane "truncate, but don't NULL-terminate," or strcpy's "cause a buffer overflow," but we'll ignore those because they're obviously bad. Both truncation and failure to write anything can lead to bugs if the programmer fails to check the return code of the copy function.
Given this, strlcpy seems the best possible choice, since it at least defines what the output should be in the case of failure, whereas strcpy_s and similar functions do not.
> third, i very much hope the snprintf comment was just a
> silly programmer's joke. otherwise please stop writing code.
Another opinion presented without justification. snprintf is fast, and it checks buffer sizes. There is absolutely no reason to use it, especially when glibc refuses to provide saner string copying interfaces.
And before you spout more confusion, you can easily check whether snprintf truncated the input-- and I almost always do, unless it truly is irrelevant.
Posted Mar 28, 2012 20:48 UTC (Wed) by PaXTeam (subscriber, #24616)
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\
Posted Mar 29, 2012 1:16 UTC (Thu) by cmccabe (guest, #60281)
What have you proposed? You linked to a web page with a proposal for strmcpy. When questioned about that, you said that you didn't agree with everything on the web page, without clarifying which parts you agreed with and which you didn't. As far as I can see, the question of what you are actually proposing remains unanswered.
Also, I would prefer that we keep the name-calling to a minimum. Remarks about "my mental capacity" are uncalled for. I realize that my earlier post might have been a little too aggressive, but let's not take this down to the grade school level.
> > snprintf is fast
> yeah dude. it smokes str*. /o\
snprintf performs better than a naive implementation of strlcpy. I have benchmarked this.
Posted Mar 29, 2012 13:42 UTC (Thu) by PaXTeam (subscriber, #24616)
you'd know if you had actually cared to read *all* my comments in this thread. as far as i see it, you want to argue about the color of the bikeshed whereas we haven't even established that it's a good idea to have one. go read the rest in my comments, i won't repeat them here. if you still have an argument then, i'm all ears.
> snprintf performs better than a naive implementation of strlcpy. I have benchmarked this.
an optimized library implementation against a 'naive implementation'? without providing any numbers, any context, any details, anything whatsoever? and you're wondering why people are not taking you seriously? /o\
Posted Mar 29, 2012 7:30 UTC (Thu) by ekj (guest, #1524)
If the best you can do is tossing characteristics like 'mental capacity' around while lamenting about lack of past performance, and in going for the man rather than the ball - then please go somewhere else than Lwn.
And no, adding smileys after every uncalled for personal attack does not make it okay.
Posted Mar 29, 2012 13:47 UTC (Thu) by PaXTeam (subscriber, #24616)
i actually have, you'd just have to read my earlier comments. have you? i didn't see any feedback from you at least.
as for name calling, etc: you might want to check up on your friend's earlier comments and his tone towards everyone else who didn't see the wisdom in strl* the way he does. but then it seems you too have reading comprehension problems and nothing useful to add except for 'going in for the man rather than the ball'. will you take your own advice then?
Posted Mar 23, 2012 8:18 UTC (Fri) by pdewacht (subscriber, #47633)
Posted Mar 26, 2012 11:54 UTC (Mon) by jwakely (subscriber, #60262)
Posted Mar 26, 2012 13:30 UTC (Mon) by nix (subscriber, #2304)
Posted Mar 26, 2012 14:28 UTC (Mon) by jwakely (subscriber, #60262)
Posted Mar 28, 2012 18:22 UTC (Wed) by nix (subscriber, #2304)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds