Re: [PATCH RFC] Update/correct copyright notices

[Kevin Buettner <kevinb@cygnus.com>]

On Mar 1, 10:30am, Eli Zaretskii wrote:

> > 	* ax-gdb.c breakpoint.c coffread.c corelow.c dbxread.c
> >  	dwarf2read.c dwarfread.c elfread.c eval.c exec.c infcmd.c infrun.c
> >  	mipsread.c nlmread.c os9kread.c parse.c printcmd.c symfile.c
> >  	symmisc.c symtab.c thread.c top.c tracepoint.c typeprint.c
> >  	valops.c: Cast parameters passed to make_cleanup to use the new
> >  	make_cleanup_func typedef.
> > 
> > The script regarded this list of files as a sentence instead of a
> > file list because they're not comma separated.  I'm still mulling
> > this one over and may think of a way to change my script to accomodate
> > this type of error.  (It's likely that it occurs elsewhere too.)
> 
> If we are going to rely on ChangeLog's for something that affects
> source files, we had better routinely check and fix any invalid
> entries such as the one above.  I don't think it's right for the
> script to deal with such breakage: it is too dangerous.

Well, I did modify the script to deal with the above problem and I
think it's better to attempt to deal with it than not.  However, I
agree that it would be better for all of the ChangeLog entries to
conform to the standard.  I've been thinking about writing a lint
program for ChangeLog files.

I think the danger in this instance is minimal; if the script
inadvertently decides that a sentence is a list of filenames, it will
likely just end up generating warnings for a bunch of files that it
can't find.  The criteria that the script uses at the moment for
deciding whether a list of space delimited "words" is a filename list
or a sentence is to see if over half of the "words" have a dot in them
followed by an alphanumeric character.  If they do, the "word" list
is considered to be a list of filenames, otherwise it is a sentence
(which is discarded anyway).

[...]
> > Yes, the use of ``*'' as a filename wildcard in ChangeLog entries is
> > really quite annoying.  There were also entries that said foo.[hc] or
> > sometimes {foo,bar}.c (or sometimes a combination of the two), but I
> > was able to handle these cases.
> 
> These are all invalid entries, they go against standards.texi.  We
> should simply fix them by hand, I think.

Yes, that would be good if we can.  Unfortunately, this may prove to
be rather difficult since the wildcard specifications refer to some
set of files that existed in the past.  For some of the more recent
ones, someone at Red Hat could do a ``cvs checkout -D'' on Red Hat's
internal repository to see the files that were in existence at the
time.  I suppose we could dig up old snapshots or old FSF releases to
fix the situations which predate the use of CVS.

I think the following entry might be one of the harder ones to fix:

Tue Jul 12 19:52:16 1988  Peter TerMaat  (pete at corn-chex.ai.mit.edu)

	* Makefile, *.c, munch, config.gdb, README: New initialization
	scheme uses nm to find functions whose names begin with
	`_initialize_'.  Files `initialize.h', `firstfile.c',
	`lastfile.c', `m-*init.h' no longer needed. 

Fortunately, because it's so old, I think it poses little danger to
the fixdates script.  The *.c files in question were likely under heavy
development at the time and very likely are referred to explicitly by
other ChangeLog entries form the same time period.  Also, my script
does preserve those copyright years found in the notice which
predate any mention in the ChangeLog.

Kevin