Maybe I can clarify one thing. strnlen() is one of the "newer" string (and perhaps a few other) functions that was still in draft status under the Austin group ( http://www.opengroup.org/austin/ ) at the time it was added which was PSARC 2006/617, added in build 54 according to http://hub.opensolaris.org/bin/view/Community+Group+on/51-55
At that time, there was a need for such a function (all the discussion I can find is merely referenced in a summary https://www.opensolaris.org/jive/thread.jspa?messageID=64602 so I assume the clearview folks were the ones that needed it). I'd pointed out that strnlen() was the well-known answer to the problem, and that many existing implementations (as well as the Austin group draft description) were compatibly described. So it ended up in libc (and I'm told, in the kernel too, because it was also needed there). There seemed to be little interest at the time in pursuing all the rest of the functions in the then-draft standard that weren't present in Solaris. And unfortunately, when the standard started to be approved by various bodies in 2008, no interest in adding all the new stuff seemed to materialize. Don Cragun used to be the point man on standards, but at some point (don't remember when) he left Sun to work elsewhere. He still participates here from time to time, but I don't know that he or anyone ever had much luck being proactive. I can understand not _integrating_ anything of less that rock-solid consensus and stability before the standard is approved. But IMO, someone should have been keeping track of the new stuff, and had code ready and a clear understanding of its implications, so the missing stuff could have been added very quickly. One strength that Solaris once had that Linux never cared about nearly as much (given the notion that if both OS and apps are open source, anyone can patch and recompile) is _standards_. Unix, especially the otherwise (before SVR4) pedestrian System V lineage, was all about standards even before there was POSIX. The System V Interface Definition (SVID) formally separated specification from implementation (even though that specification was based in large part on the existing man pages, minus some things chosen for whatever reason to be left out, and plus extra details as needed, and eventually, plus separate platform ABI definitions as well - in principle, binaries from various x86 implementations should have been able to interoperate, although in practice even where it might work, different shared libs and such made that rare). That formal separation of spec from code adds immense stability. The discipline is a very useful practice for understanding a large set of interfaces, as well. But app developers want to be able to _assume_ the existence of the largest possible toolkit. (laziness is _usually_ a virtue for programmers) So many app developers (those more interested in a single platform than in making there app as widely used as possible, and those less acquainted with the practical benefits of standards, or grown cynical because of seeing the standards or their implementations so far behind) gravitate to the place that has the largest toolset. And from their standpoint, it's not Solaris, or even OpenSolaris, that has that anymore. At _least_ vigorously tracking released standards is IMO crucial, because without it, the argument that standards provide a basis for discipline and portability falls apart. I would very much like to see someone compare the OpenSolaris section 3* man pages to The Open Group Base Specifications Issue 7 / IEEE Std 1003.1™-2008 see what's what's missing, and get busy adding it. I would even do some of the research and coding myself. What I won't do is spend a lot of time arguing about it and jumping through hoops. -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
