> The problem with strlcat and strlcpy is that they assume that it's okay to arbitrarily discard data for the sake of preventing a buffer overflow. The buffer overflow may be prevented, but because data may have been discarded, the program is still incorrect. This is roughly analogous to clamping floating point overflow to DBL_MAX and merrily continuing in the calculation.
Just to be clear, someone else wrote that response. It's unclear if the maintainer had the same thought process. They probably did to be fair, but the fact that they decided to throw an incoherent tantrum instead is not very helpful.
The argument is also totally wrong because the whole point of strlcpy is to copy the string and, if it fails, calculate the amount of storage that was really required, without making two passes over the data that does fit. The fact that the too-small buffer is overwritten with a truncated copy of a string is just a side effect.
Eh, to be fair, if doubles are overflowing past DBL_MAX, things went off the rails in your code quite some time ago, and it doesn't much matter what the exact overflow behavior is.
A better example would be signed integer overflow, which a conspiracy of spec authors who don't work in the real world and compiler maintainers with a perverse sense of humor have decided means "Anything goes."
He was not that wrong!