> > > 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
You enjoy pain, don't you? ;-) > > > ./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 ?) ... :-) Ah :-) > > > ./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 ? Just that "some kind of iffe-like probe" seems nebulous. How confident are we that we understand its purpose and relationship to Solaris? > 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. Maybe I'm not being creative enough, but if it's really an overlay, then the interface definitions should be compatible, right? I would've thought that astsa would be a semantically compatible subset of the functionality available in the non-standalone environment, and thus that removing the standalone headers would not cause problems -- especially not at runtime. > 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) ? Yes, I'd like to keep findunref's output reproducible. > ... 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) ? For hygiene reasons, we don't permit exceptions that are not actually being used. There is another tool (checkpaths) that will enforce this. (Yes, we're really *that* picky about this sort of stuff.) > > ./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... :-) Even better :-) > > each resync: > > > > */Mamfile > > */Makefile > > AFAIK "*/common/Makefile" would be better (OkOk, nitpicking... :-) ) ... I agree it would be better. > > 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... Cool. > > ./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. So does that mean that the above are actually referenced on a SPARC build? -- meem
