From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Eli Zaretskii Cc: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com Subject: Re: [PATCH RFC] Update/correct copyright notices Date: Thu, 01 Mar 2001 01:19:00 -0000 Message-id: <1010301091920.ZM19108@ocotillo.lan> References: X-SW-Source: 2001-03/msg00005.html 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