> > [ This is a bit far-afield for Clearview at this > point; feel free to > move this discussion to osol-code or the like. ]
I'm on the web interface right now, but I'll try to have it cc osol-code so that we can continue there. > > * (gulp) _What am I getting myself into?_ (fears > of long arguments > > (although this is infinitely smaller and less > problematic than ksh93, > > for example), not to mention intense loathing of > stacks of paperwork, > > many hours consumed, etc) > I think this case will go through the ARC trivially, > especially given > existing precedent in glibc. Here's hoping... > > * completeness (1): I would expect this needs to > have a declaration > > added in <string.h>. What I don't know is what > feature tests or the like > > would be needed for compliance with various > standards to determine > > when that declaration should and shouldn't be > visible. Further, some > > googling suggests strnlen() is under consideration > for future revision to > > POSIX; hopefully it's an obvious enough parallel to > strlen() that the > > committees in their august wisdom go with that > obvious parallel, but > > if not, early introduction would lead to a need for > both backwards > > compatible and standards-compliant versions, or > for the early version > > to be regarded as unstable or evolving, until > blessed by a supported > > standard. > > > > > http://www.opengroup.org/austin/plato/uploads/40/9756 > NAPI_overview.txt > > I notice that strsignal() is also in that list; > that's currently already > in our string.h>, so I'd think you could put this > under the same ifdefs to > prevent it from being visible when doing a > standards-conforming compile. Good point; you went a step beyond what I did there. That looks like #if defined(__EXTENSIONS__) || !defined(__XOPEN_OR_POSIX) ... for now. > > * completeness (2): there really ought to be > parallel optimized assembler > > versions of this (as with many of the other str*() > and mem*() functions), > > but I don't think I can get good enough at > assembler fast enough to be > > of any use with that. > > I don't think that's necessary until there are more > users of strnlen(). > In general, those additional implementations come at > a maintenance cost. Ok. > > * completeness (3): needs a man page. ISTR > writing nroff man pages in > > the depths of time, but I don't know about properly > phrased disclaimers > > in the face of evolving standards, etc. > I think it can simply be added to string(3C); there > are already plenty of > non-SuS interfaces listed there, such as strlcpy(). Ok. > > Also: > > > > * there's a private (?) implementation in > apptrace: > > > > > http://cvs.opensolaris.org/source/xref/on/usr/src/lib > abi/apptrace/common/interceptlib.c#52 > > > > that looks a lot like the GNU version (i.e. calls a > mem* function > > rather than doing all the work itself), but also > deals with the special > > case of the pointer being passed as NULL (although > I'm not sure that it > > should in a general purpose implementation, let > alone whether their > > response is sound) > > It doesn't appear that strnlen() implementation is > used anywhere, so I > don't think this is an issue. You can just haul it > out. Ok, I'll ignore that for now. I was just looking at precedents in terms of the behavior of private implementations. > > * various sfw software has private > implementations. If any of them > > configure to use a libc implementation if > available, then perhaps their > > builds and/or resultant executables would need to > be tested; that's > > beyond what I'm prepared to do. > > Assuming we provide the same interface that other > Unix variants provide, I > don't think rigorous testing is needed here. It > shouldn't be too hard to > have someone inside Sun build the SFW gate using a > machine that has a > prototype of your fixes and then check the resulting > objects to see if > they're using the new libc version of strnlen(). Ok. As long as I don't actually have to have my own build environment set up, I'm good then. While I've got a couple of systems running SXCR (sparc build 41 and x64 build 39 I think), neither has the space for even an ON build environment, let alone ON+other stuff. (what do you expect from a collection of toys...) This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
