Peter Memishian wrote: > > > > Taking dirstd.h as an example, it says: > > > > > > 23 /* > > > 24 * AT&T Bell Laboratories > > > 25 * > > > 26 * <dirent.h> for systems with no opendir() > > > 27 */ > > > > > > It's impossible that opendir() will disappear from Solaris, so this file > > > will never be useful. How can it be argued that this "may" be used in > > > future work? > > > > The the matching codepath is AFAIK used for FS3D support, too. From > > "usr/src/lib/libast/common/dir/dirlib.h": > > Hmm, I don't know much about FS3D, but I find it highly unlikely that > proper Solaris support for it would involve interposing on the libc *dir() > routines. Instead, I'd expect that we'd build support into the *dir() > routines themselves. In other words, architecturally, this doesn't seem > like a direction we'd ever pursue with Solaris. At the same time, this is > a tiny file and I don't think it's worth complicating future merges for > the sake of its removal.
I just checked this with standalone builds (debug+non-debug, 32bit+64bit) of ast-open (the superset of the AT&T ast-ksh package) - it seems that something like $ mv ./src/lib/libast/dir/dirstd.h ./src/lib/libast/dir/dirstd.h_disabled # doesn't affect the build on Solaris (short: I was wrong and the file can go... :-) ). > As an aside: it seems like the comment atop dirstd.h is wrong and needs to > be corrected in the upstream source. > > > All of them which are currently listed as "unused files" are > > _currently_" simply irrelevant to Solaris" in _today's_ configuration. > > Except for the one that turned out to be a bug (as you noted below). > Those sorts of bugs are one of the reasons I've been requesting more > information -- we've found similar cases over the years in ON. Ok... > > This is one of the problem we have with the "unused files" - we don't > > know how our future will look like and what exactly we will need of the > > features which are available. > > I understand -- which is why I think the project team's expertise is > needed to find a reasonable dividing line. Agreed... > > To answer your question above more detailed: > > ./lib/libast/common/misc/magic.tab > > > > Magic number database (see file(1). Not used yet but may be usefull to > > look later to get the /usr/bin/file tool+database updated). > > This seems very questionable to me; the database at cmd/file/magic will > always be the authoritative source for ON. If it's out-of-date, then > libast's magic.tab -- along with many other similar databases -- should of > course be consulted to update it. Slightly offtopic: Actually my long term plan is to _fix_ /usr/bin/file. The current version has a couple of design problems (for example the assumption that exactly one (content) pattern matches exactly one type of file (which isn't true and most more "modern" implementations of a filetype detection facility like the Amiga DataTypes, CDE, FreeDesktop's mimetype database etc. have adopted a concept of "choices" (e.g. one file may match multiple file types (for example "DocBook/XML" files could match "docbook document", "XML file" or "ASCII" file)))) and missing features which should be fixed. > But I see no reason to drag libast's > magic.tab into ON just for such a purpose. Ok (note that we may get that file back if we include something like AST's version of the "file" utility (not planned yet, don't worry... :-) )) ... > > ./lib/libast/common/port/astmath.c > > > > Test code for AST math functions. > > So that goes in the list of test exceptions we talked about before. Ok... > > ./lib/libast/common/port/atmain.C > > > > at stubs (not used on Solaris (unless someone writes something like > > BrandZ/MVS ... =:-) )) > > This seems highly unlikely to be relevant. Right (you did see the "devil" smiley (e.g. "=:-)"), right ?) ... :-) > > ./lib/libast/common/port/lc.tab > > > > l10n/i18n table (like "math.tab" ; the table+infrastructure is on my > > list to be tweaked/enhanched for Solaris once we make some libast APIs > > more open). > > This seems worth keeping then. Ok... > > ./lib/libast/common/port/lcgen.c > > > > This is used to generate AST's <lc.h> tables from the table above. > > Likewise. Ok... > > ./lib/libast/common/regex/regdecomp.c > > > > Uhm... now I am confused. This piece should be compiled in... > > ... grumpf... wonderfull... we found a bug... ;-( > > Funny that ;-) Fixed (see http://bugs.grommit.com/show_bug.cgi?id=195). [snip] > > ./lib/libpp/common/ppsym.c > > > > Some kind of "iffe"-like probe to figure out the list of CPP predefined > > symbols. > > I'm still lost on this one, but OK. Erm... which question do you have about this ? > > ./lib/libshell/common/bltins/shopen.c > > > > That's the "open" builtin command. Not used for now but may be later > > usefull for some scripts which have to open files with non-standard > > flags (e.g. |O_DSYNC|, |O_NOCTTY|, |O_NOFOLLOW| or XATTR files). > > This seems worth keeping then. Ok... > > ./lib/libshell/common/sh/env.c > > > > Contains an API to modify environment variable pools. The matching > > codepath (follow |_ENV_H| in the libshell sources) is currently not used > > on Solaris (see problem above about "codepaths we do not use _now_"). > > Likewise. Ok... > > > Is it correct to say that the entire `astsa' directory could simply be > > > lopped off? Or are there some files in there Solaris uses? > > > > AFAIK none of the files in usr/src/lib/libast/common/ are used by our > > libast.so.1 build... however I am little bit scared to drain&&remove it > > because it's in the global include searchpath of the libast build. > > That seems a bit of a contradiction. Seems like we don't really know if > it's used or not. Or are you worried about a future dependency being > introduced? I am worried since it is in the default search path for includes which means noticing cases like "cc -Ioverlay/ -Inormal/ mychicken.c # where both overlay/ and normal/ contain a version of 'x.h'" may cause (undetected) trouble if "overlay/x.h" gets removed, e.g. this scenario may compile but the results may... uhm... not something you really want. That's why I said I am little bit scared in this case. > > Another problem is that standalone tools like the tools which parse > > tables and generate code may depend on these includes (to overlay > > "normal" AST&&system includes in some cases) making this a little bit > > tricky to sign a statement which says "... these are not used...". From > > what I know today I think these could be removed (in theory... with some > > uncertain feeling in my stomach...). > > Well, you know what my preference would be :-) > > To summarize, it seems like the following exceptions should be added to > findunref: > > [ Add these to the general "documentation file exceptions" section. > For the documentation that's just in text-file form, it would be nice > if the upstream source could rename them to end in .txt so we didn't > need these exceptions :-) ] What about using something like /usr/bin/file to detect the file type and get "findunref" to complain only if such files do not have the right type (Ok... the problem would be that this would read the files and therefore alter the access timestamp) ? > */BUGS > */COMPATIBILITY > */DESIGN > */HISTORY > */OBSOLETE > */RELEASE* > */NOTES > *.[1-9] > *.memo > *.mm Looks Ok... ... what about adding *.xml or *.docbook to this list of files (assuming that some day we get some documentation written in DocBook into the tree) ? > # > # Ignore ksh93/ast-related files that are only used to resync our build > # configuration with upstream. > # > ./lib/libast/common/features/* > ./lib/libast/common/comp/conf.* > ./lib/libast/common/port/lc.tab > ./lib/libast/common/port/lcgen.c > ./lib/libcmd/common/features/* > ./lib/libdll/common/features/* > ./lib/libshell/common/features/* > ./lib/libshell/common/data/math.tab > ./lib/libshell/misc/buildksh93.ksh > ./lib/libshell/misc/*.diff Erm, the current list of *.diff files will be removed. The current *hotfix*.diff is only for the "getconf" glitch April found and will be fixed with the next update from upstream and Glenn did a small modification which allows us to include our list of builtins without touching the AST sources. Therefore we AFAIK will not need any *.diff files for now... :-) > ./lib/libpp/common/gentab.sh > ./lib/libpp/*/pp.* > > # > # Ignore ksh93/ast-related test programs. > # > ./lib/libast/common/port/astmath.c > ./cmd/ast/msgcc/msgcc.tst > > # > # Ignore ksh93/ast-related source components that are not currently > # used but may be useful later. > # > ./lib/libshell/common/bltins/mkservice.c > ./lib/libshell/common/bltins/shopen.c > ./lib/libshell/common/data/bash_pre_rc.sh > ./lib/libshell/common/include/env.h > ./lib/libshell/common/sh/bash.c > ./lib/libshell/common/sh/env.c > ./lib/libshell/common/sh/shcomp.c > ./lib/libshell/common/sh/suid_exec.c > > ... and the following should just be pruned from the upstream source on > each resync: > > */Mamfile > */Makefile AFAIK "*/common/Makefile" would be better (OkOk, nitpicking... :-) ) ... > ./lib/libshell/common/mamexec > ./lib/libshell/common/mamstate.c > ./lib/libast/common/astsa/* > ./lib/libast/common/uwin/mini.sym > ./lib/libpp/common/probe.win32 > ./lib/libast/common/misc/magic.tab Ok... > That leaves five files which are less clear-cut, but could probably also > end up in the findunref exception_list. > > ./lib/libast/common/dir/dirstd.h > ./lib/libast/common/port/atmain.C These two can go... > ./lib/libpp/sparc/gentab > ./lib/libpp/sparc/probe > ./lib/libpp/sparc/probe.sh AFAIK we should keep them - AFAIK April's original list of "unreferenced files" did not include "lib/libpp/i386/probe.sh", "lib/libpp/i386/probe" or "./lib/libpp/i386/gentab" either. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
