| |||||||||||||
Still no strlcpy and friendsStill no strlcpy and friendsPosted Mar 23, 2012 20:21 UTC (Fri) by cmccabe (guest, #60281)In reply to: Still no strlcpy and friends by PaXTeam Parent article: GNU libc 2.15 released
> a quite thorough and recent examination is here: http://byuu.org/articles/programming/strcpycat
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*)
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.
(Log in to post comments)
Still no strlcpy and friends Posted Mar 24, 2012 13:58 UTC (Sat) by PaXTeam (subscriber, #24616) [Link]
first, i referenced that blog for explaining some of the problems with strl* (i note you didn't reflect on that though), not to pass judgement on his solution (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).
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.
Still no strlcpy and friends Posted Mar 24, 2012 16:23 UTC (Sat) by tjc (subscriber, #137) [Link]
I've always found snprintf to be a reasonable alternative to strlcpy, and I remain unmoved by your contempt for programmers who use it! :)
Perhaps an a well-reasoned explanation as to why you think its bad would persuade me otherwise...
Still no strlcpy and friends Posted Mar 24, 2012 18:16 UTC (Sat) by PaXTeam (subscriber, #24616) [Link]
if strlcpy is the best fit for a particular problem then you don't 'emulate' it, you use it. and if it's not present in your system then you implement it.
Still no strlcpy and friends Posted Mar 28, 2012 18:39 UTC (Wed) by cmccabe (guest, #60281) [Link]
> first, i referenced that blog for explaining some of the problems with
> strl* (i note you didn't reflect on that though), not to pass judgement on > his solution
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
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
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
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.
Still no strlcpy and friends Posted Mar 28, 2012 20:48 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> If you agree with some of his analysis but disagree with other parts
> (including the conclusion), what's the point of linking to it?
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
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\
Still no strlcpy and friends Posted Mar 29, 2012 1:16 UTC (Thu) by cmccabe (guest, #60281) [Link]
Look, at the end of the day, this is a debate about best practices. I have proposed using strlcpy rather than strcpy to copy a variable length string into a fixed-length buffer as a best practice. And if strlcpy is not available, I propose using snprintf.
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.
Still no strlcpy and friends Posted Mar 29, 2012 13:42 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> What have you proposed?
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\
Still no strlcpy and friends Posted Mar 29, 2012 7:30 UTC (Thu) by ekj (guest, #1524) [Link]
If you have an actual argument, make it.
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.
Still no strlcpy and friends Posted Mar 29, 2012 13:47 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> If you have an actual argument, make it.
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?
|
|||||||||||||