James Carlson wrote: <snip>
Note: I am replying only to strsep() related discussion for now. > 754: you should have your sponsor (at least) update those CRs to > reference this file as being another copy. If I were an RTI Advocate > (I'm not), I'd probably be less generous: I'd say that if you know > about a problem (lack of common C library function), and you're adding > to the problem (yet another copy), then you're now on the hook to fix > it, even if you didn't cause it in the first place. (But, like I > said, I don't have that authority. :->) The plan is to wait for strsep() to be integrated into libc and then proceed with putback of CR 6691168. Just to be clear: I am not in favor of providing another copy of strsep() (or any other similar function). The strsep() is included only for testing purposes. I have talked with other engineer and there seems to be a queue of people lining up for strsep() in libc. > Ditching strsep and using strtok would avoid that particular problem. The catch with this approach is that strsep() makes syntax parsing (with error detection) easier (than with strtok()). >> The fix incorporates a function called strsep() which is about to get in >> libc in the future but is not available so far (see CR6487100 & >> 4383867). So don't wonder about the implementation of strsep() inside >> the netcat.c. > > Strange ... one of those two CRs appears to be a duplicate. I have just closed CR 6487100 as a dup and provided a link to a comment about native implementation (str[c]spn()) which was part of 6487100. The point of that comment is that neither strtok() or strsep() have flaws so str[c]spn() (which does a better job) should be used instead in internal code. Maybe another thing worth investigating in the context of this RFE. v. _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
