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.
Re:Open source can't coordinate
by johhnylately535 on Friday June 20, 2025 @11:38AM
(#44328762)
I believe the responder is here on HN as kazinator. I remember him from back in the day.
Isn't the point that it's harder to use those interfaces wrong then the null terminator stuff?
Re:Open source can't coordinate
by cl0ckt0wer on Friday June 20, 2025 @10:49AM
(#44328240)
Don't let perfect be the enemy of good
Making changes to ultra-core stuff like glibc is not really a "move fast and break things" area.
Nor is it a "never change" area. At least it shouldn't be.
Wow so “Linux didn’t get it for 25 years because the glibc maintainer is a jerk” is an oversimplification??? Shocking.
Re:Open source can't coordinate
by CamperBob2 on Friday June 20, 2025 @11:27AM
(#44328636)
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."
Re:Open source can't coordinate
by cornstalks on Friday June 20, 2025 @12:50PM
(#44329608)
That argument sounds totally wrong because you can easily detect truncation:
if (strlcpy(dst, src, dst_len) >= dst_len) {
// Truncation!
}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.
He was not that wrong!