Linked by Thom Holwerda on Wed 6th May 2009 17:41 UTC, submitted by diegocg
Thread beginning with comment 362129
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Let's hope Drepper's not a filesystem designer
by Soulbender on Wed 6th May 2009 19:45
in reply to "RE[2]: Let's hope Drepper's not a filesystem designer"
strl*
by sakeniwefu on Thu 7th May 2009 05:18
in reply to "RE[2]: Let's hope Drepper's not a filesystem designer"
I think that they are overrated: they can avoid certain classes of errors, but in many cases string truncation is an error, period, and the real flaw is the use of fixed-length buffers.
Well, it might be a flaw in Java, but I hope you realize the sort of code that should be using these functions isn't in the same league as Java applications. Anyways, the main application for strl* is variable-size string buffers so I don't really see your point.
strl* functions are either or both faster and technically superior to all competitors in the same league. All alternatives are either unusable, slower, error prone or all of the aforementioned. An especially useless alternative is Microsoft's strncpy_s which fails to replace both strlcpy and strncpy for the few legitimate uses the latter has.
Still, if truncation is an error in your aplication, you should check for it. What are you suggesting strlcpy should do that it doesn't? Cry all over the place like strncpy_s?






Member since:
2006-01-11
While it might be a good idea to put these functions in, because so many want them, I think that they are overrated: they can avoid certain classes of errors, but in many cases string truncation is an error, period, and the real flaw is the use of fixed-length buffers.