Testers needed for ISO C Binding patch

[Brooks Moses]

Tobias Schlüter wrote:
> Steve Kargl wrote:
>>> I'll try fixing this later tonight by following the testsuite manual's 
>>> recommendation of not including system headers, but instead writing the 
>>> required prototypes explicitly.
>> Never seen that one either :-\
> 
> Fixed in the described fashion.  Committed to the branch.  I'm still 
> waiting for the testsuite to finish, but it looks like I'm getting a 
> clean run with this fix.

Could you please post the patches that you commit, even when they're 
committed to the branch rather than trunk?  :)

>> You'll note a lack of proper ChangeLog entry in that Chris has been
>> working on this patch for what must be approaching 2 years.  Detailing
>> all of the changes would probably have given FX a stroke.
> 
> That's certain, I'm somewhat worried about clause 2a of the GPL:
> "You must cause the modified files to carry prominent notices stating 
> that you changed the files and the date of any change."

My personal (non-legal, not speaking for CodeSourcery or the FSF) 
opinion on this:

As far as the letter of the law is concerned, the GPL is irrelevant to 
changes made on the official tree.  All GCC code is copyrighted to the 
FSF, and thus the FSF does not need to obey any licenses at all (other 
than its agreements in the copyright-assignment letters with the 
contributors) in order to distribute the code.  In particular, the FSF 
can distribute modified versions of GCC code without following the GPL's 
requirements for modifications.

As far as the spirit of things is concerned, I also think that this 
clause is irrelevant beyond what GCC already does for more "normal" 
situations.  The clause is intended for cases where one person is 
distributing a modified version of someone else's code, in order to 
clarify which things were part of the original distribution and which 
were added in the modified form.  Here, this is all the original 
distribution.

> But with no means to reconstruct when which changes happened, we can 
> probably think of the branch merge date as the modification date?

Yes; note that ChangeLog entries are _always_ the date that the changes 
were committed to the repository, not the date they were written.  This 
case is merely an instance of that practice -- for merging this to the 
trunk, the date that the files _on trunk_ were changed is the date of 
the merge, and that is the date that should go into the main ChangeLog.

(In particular, that is what should happen _regardless_ of whether we 
have records of when the changes happened on the branch and in Chris's 
private files prior to the branch creation.)

The only other place that dates appear in current GCC practice is in 
copyright dates in the files.  Is is to be hoped that Chris has already 
filled those out accurately in the files which he contributed.

- Brooks