Alejandro Colomar (man-pages) <[email protected]> wrote: > However, considering some systems don't have strl* functions, and > explicitly don't want to add them (glibc rejected strl* functions), > there it might be useful to add this function.
So your position is that when a small number of people fight the emergence of a problem-solving standard, the answer to the adoption-problem is to propose yet another another choice? Which they can also fight against? I've seen your proposal before, elsewhere. The glibc people have also ignored you. You need to read the room... Programmers don't need to remember in their mind the semantics of yet-another string function, when suitable ones already exist. Some history. Around 2000, we were auditing and repairing a huge source tree. We started this work by using the ANSI standardized functions, and we found the bounds-checking gymnastics too be too hard to get right (and thus, little wonder why there were so many buffer overflows in C code using the ANSI functions). So we wrote strlcpy to ease our repair of the entire tree. It was only after the easier audit process experience that we started telling the world about our success with strlcpy, coupling it with the message that we had repaired an entire source tree with it. The message was: since it had worked so well for us, maybe others might like it also. Your proposal comes with no similar pedigree, so your pushiness of this proposal on various mailing lists seems to be driven by ego. I'm done here.
