We've been considering proposals to add common POSIX APIs into C, but I don't believe we've seen a proposal for strlcpy or strlcat yet. I recall we agreed to add strdup to C given its wide availability and usage.
There are deficiencies in almost all proposals. Two new functions which avoid the problems are supposed to be published in C202x: strcasecmp and strncasecmp, added in header strings.h (note: not string.h).
In fact I proposed strdup on a few occasions, but it wasn't adopted. It seems that they didn't like for standard library functions to use malloc.
POSIX.1 specifies strdup.
No one has proposed making these standard. I doubt they would gain much support as they are similar to the Annex K Bounds Checked Interface functions strcpy_s and strcat_s but not quite as good IMHO.
There were a number of recent proposals to adopt various POSIX functions by Martin Sebor into C including:
N2353 2019/03/17 Sebor, Add strdup and strndup to C2X
N2352 2019/03/17 Sebor, Add stpcpy, and stpncpy to C2X
N2351 2019/03/17 Sebor, Add strnlen to C2X
6.33 Sebor, Add strnlen to C2X [N 2351]
Result: No consensus on putting N2351 into C2X.
6.34 Sebor, Add stpcpy, and stpncpy to C2X [N 2352]
Result: No consensus to put N2352 into C2X.
6.35 Sebor, Add strdup and strndup to C2X [N 2353]
Result: N2353 be put into C2X.
The committee wants a proposal for the wide character versions of any POSIX
functions voted in this meeting.
There have been some disagreements on strlcpy/strlcat (BSD vs glibc crowd), although by now the debate has died off and these functions are pretty widely used. Also, while here, it would be lovely to have strchrnul() included.
> similar to the Annex K Bounds Checked Interface functions strcpy_s and strcat_s but not quite as good IMHO.
Err... I thought Annex K is deprecated and dead? Whereas strl* seem very much alive, some compilers even give a "strcpy/strncpy is unsafe, use strlcpy instead" warning.
Correct -- it would be nice if the glibc maintainers would reconsider their opinion of supporting the optional Annex K functionality. There is definitely user demand for the feature.
> The C Committee has taken two votes on this, and in each case, the committee has been equally divided. Without a consensus to change the standard, the status quo wins.
The fact that it has only survived on status quo is a pretty crass hint that things aren't well with Annex K.
> Microsoft Visual Studio implements an early version of the APIs. However, the implementation is incomplete and conforms neither to C11 nor to the original TR 24731-1.
> As a result of the numerous deviations from the specification the Microsoft implementation cannot be considered conforming or portable.
Well, I am informally proposing making those standard :-).
IMO they're a lot more ergonomic than the Annex K functions, and do the thing most programmers think the strncat/strncpy functions do (admittedly, not part of ISO C).
Annex K should be forgotten as the mistake it is and we can move on with existing real-world interfaces instead of inventing features from whole-cloth. I thought that was generally the C standard operating practice.
