Recent Features
| |||||||||||||
That's a non-problemThat's a non-problemPosted May 20, 2009 18:56 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: That's a non-problem by elanthis Parent article: EGLIBC: Not a fork, but a glibc distribution
aren't the strlcpy() family of calls included in the latest posix spec?
(Log in to post comments)
That's a non-problem Posted May 20, 2009 22:15 UTC (Wed) by msbrown (subscriber, #38262) [Link]
No, the strl* family is not in POSIX 2008. They were proposed but rejected since they did not really solve the problem (as pointed out above).
and what would they standardize? Posted May 21, 2009 4:27 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] The OpenBSD strlcat has different behavior than the Solaris strlcat, which makes it a problem to use the function in a portable application.
That's a non-problem Posted May 21, 2009 11:11 UTC (Thu) by ncm (subscriber, #165) [Link]
We can point to strtok() and gets(), already in POSIX, as interfaces even more stupid than strlcpy(), but that hardly seems like a compelling argument for inclusion.
That's a non-problem Posted May 21, 2009 17:05 UTC (Thu) by madscientist (subscriber, #16861) [Link]
gets() and strtok() are in POSIX because they're in the ISO C standard runtime library, and POSIX includes the ISO C standard library in its entirety by reference.
That's a non-problem Posted May 21, 2009 0:11 UTC (Thu) by dododge (subscriber, #2870) [Link] ISO/IEC TR 24731-1 adds bounds-checking functions to the Standard C library, but it's still just a draft. The proposed functions use a "_s" suffix with existing function names. The group explicitly rejected thestrlcpy name because they want to provide a large consistent suite of these functions in one shot -- not just basic string operations but also things like tmpfile_s, vfprintf_s, asctime_s, wmemcpy_s, and many others. According to the associated Rationale, strcpy_s also performs more checks and has more elaborate error handling than strlcpy.
|
|||||||||||||