Thread

Actually the fact that strncpy zero fills the remainder of the array strongly suggests that it *was* intended to be used exactly as many people are (mis)using it. filling the array automatically adds a null Zero

> terminator, except in the case when string length = buffer length. If you

did't want to automatically add a null terminator, then why zero fill the array???

In times past, it was common to have text stored in a fixed-size place, padded out with NUL bytes, and no expectation that there would be a NUL at the end. I know this seems strange today. Perhaps it is for compatibility with some long-forgotten non-C language. Requiring a NUL byte would increase the size of a record, so maybe people were just trying to save space in a world where fixed-size records were the norm yet every byte was precious.

With regard to strlcpy truncating the string, how can that possibly cause a security problem???

There are plenty of ways. Perhaps code later checks the new length, then ends up filling it with the old (longer) data. Perhaps the allocation is zero bytes, strlcpy thus fails to write the NUL byte, and ultimately you leak private data. Perhaps the allocation is zero bytes, strlcpy is buggy (wrongly writing the NUL byte), and a function pointer is trashed. There is more to security than buffer overflows of course; perhaps you turn filename.exe.tif into filename.exe when you truncate. Perhaps the truncation removes a closing quote or comment mark, leading to some critical script or config data being swallowed up.

I don't see that at all. like strlcpy is doing Seems *exactly* what strcpy should have been doing for all these years to prevent

I'm not sure strcpy ever had a legitimate purpose. Use memcpy.

Either you know the length (you can use memcpy) or you don't know the length (you have a bug, truncation or otherwise).

I tend to agree regarding the use of standard implementations rather than rolling your own whenever possible. Bob F. is well versed in However, portability issues because of his support for GraphicsMagick on multiple platforms. he thinks there are enough compilers in widespread use that If don't support strlcpy to justify rolling his own, then he may be right.

I think Linux and Windows are in widespread use. :-) You can find strlcpy on *BSD and I think on recent Solaris. It has been rejected by the glibc maintainer.