Charlie said:
I agree with you. That's what I meant by "or equivalent". I have my own
implementation as well.
strlcpy was not included in the GLIBC, because they are non-believers: there
are many instances of strncpy in the GLIBC, most of which are wrong and
could have been fixed with strlcpy.
It's a shame the committee would not define a proper library function for
limited string copy and concatenation, so everybody can safely rely on a
standardized, well defined API. A revamped stream and string parsing API
would also have helped more than VLAs.
One doesn't hinder the other. VLAs are useful, and they do not disable
a correct limited string copy function! Both features have nothing
to do with each other.
The basic problem in the library is that even the zero terminated
string library is lacking such fundamental features like a replacement
for strncpy!
Since it is the only portable function there, it will go on being used
with bad consequences. Of course I am not speaking about clc regulars
that never make mistakes or "don't need" strncpy. I am speaking about
the run of the mill programmers like me, that do make mistakes and that
would like to think and do something more exiting when programming
than taking care of this STUPID details!
Yeah I know. Change the language, C is for people that are unable to see
beyond this details etc etc.
No!
It is not true. We *could* write a well designed string copy function
with a maximum limitation if we wanted. As many people have pointed out,
each one has written those... BUT
Why then it is not possible to put it in the standard document?
It could take the place of gets or other functions of the same style!