| |||||||||||||
strncpy() historystrncpy() historyPosted Jul 19, 2012 5:40 UTC (Thu) by akanaber (subscriber, #23265)In reply to: strncpy() history by tialaramex Parent article: The ups and downs of strlcpy()
Yes, that's why strncpy pads out the rest of the destination with NULs if strlen(src) < n
It's not terribly well named, it's really a function for converting between C-style null-terminated strings (src) and fixed-length records (dst). As you say it would be an insane design for a "safer strcpy", and as the article mentioned people who try to use it that way just introduce a different security hole.
(Log in to post comments)
strncpy() history Posted Jul 19, 2012 12:33 UTC (Thu) by Yorick (subscriber, #19241) [Link]
I agree that strncpy() is badly named, and that this has led people to misunderstand its function and purpose. It is still useful for (mostly legacy) wire protocols and on-disk formats where, in addition to the fixed record size, the null byte padding is important (in order not to leak any information).
By the way, strncpy() does not seem to have an obvious inverse in the C library. Perhaps sscanf can be used, but it feels a little hacky and not what I would use in code that needs to go fast.
strncpy() history Posted Jul 19, 2012 14:04 UTC (Thu) by danscox (subscriber, #4125) [Link]
The original reason for strncpy() was when directory names were limited to 14 chars. The other two bytes contained the inode number. For that particular case, strncpy() worked quite well. Yes, I've been at this for 'way too long now ;-).
strncpy() history Posted Jul 19, 2012 19:21 UTC (Thu) by smoogen (subscriber, #97) [Link]
Dear lord.. that sentence led back to flashbacks from the 80's. Thanks.
|
|||||||||||||