> > 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.
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.
> 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.
> 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. But I see no reason to drag libast's
magic.tab into ON just for such a purpose.
> ./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.
> ./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.
> ./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.
> ./lib/libast/common/port/lcgen.c
>
> This is used to generate AST's <lc.h> tables from the table above.
Likewise.
> ./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 ;-)
> ./lib/libast/common/uwin/mini.sym
>
> AFAIK this one could be removed.
OK.
> ./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.
> ./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.
> ./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.
> > 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?
> 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 :-) ]
*/BUGS
*/COMPATIBILITY
*/DESIGN
*/HISTORY
*/OBSOLETE
*/RELEASE*
*/NOTES
*.[1-9]
*.memo
*.mm
#
# 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
./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
./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
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
./lib/libpp/sparc/gentab
./lib/libpp/sparc/probe
./lib/libpp/sparc/probe.sh
--
meem
