Hacker News Reader

Comment by nomadlogic | Hacker News Reader

Seems to give more credence to: https://www.sudo.ws/todd/papers/strlcpy.html

Not really. The strlcat function is safer because it always NUL terminates the destination buffer, and therefore makes bugs in user code less likely. The flaw here is just an implementation defect.

Also note that SIZE_MAX is an unreasonable input, one would even say it violates preconditions.

> Also note that SIZE_MAX is an unreasonable input, one would even say it violates preconditions.

Annex K adds rsize_t, RSIZE_MAX, and friends, which restrict inputs to reasonable values. Unfortunately, it doesn't retcon the old functions like strncpy, and worse, no one actually implements it.

No one? I thought Microsoft implemented it, or at least an early version thereof.

A very early version. Among other differences the functions don't care about RSIZE_MAX (even though newer VS versions define and use rsize_t). However the Windows SDK contains <strsafe.h> which does limit the length of strings (STRSAFE_MAX_CCH).

https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

No, passing SIZE_MAX does not violate any precondition of strncat(), because preconditions are fixed properties chosen in advance, not something you add retrospectively when you feel like it.

The C standard does not place any upper bound on the value of strncat()'s size argument, so an strncat implementation has to work as described for all large values of the argument. It's a bug of the implementation if it doesn't, not a violated precondition.

(Reasoning about C programs has been my day job for several years. Contrary to what many think, it is possible, it only needs that the rules be set in advance and respected.)

cool!

Reply on news.ycombinator.com