Trailing white space and other pedantry.

[max]

On 05/16/2011 01:00 PM, André Hentschel wrote:
> Am 16.05.2011 18:34, schrieb max at mtew.isa-geek.net:
>> From: Max TenEyck Woodbury<max at mtew.isa-geek.net>
>>
>> I have been working on the documentation extraction problem and code
>> analysis problem.
>>
>> I have made some progress with the program I am writing to do this.  It
>> reads the same files as c2man.pl does, but does a more detailed parse
>> of the code.  In fact, it even reads and processes all the include
>> files.  It is far from complete at this time, but it does produce
>> interesting warnings.
>>
>> One of the warnings reports lines with trailing while space.  It has
>> turned up quite a few places where this occurs.  If I understand the
>> preferred style, there should not be trailing white space.  The
>> question I have is what should I do with them.  I can either fix the
>> files or turn that particular warning off.  So far, I have been fixing
>> the files on a local copy of the repository.
>>
>> Should I turn the fixes into patches and submit them, or just keep them
>> to myself?
>>
> No, white space only changes will not be accepted.
> Your are right about the preferred style, but most likely the regarding code is a bit old.
> new code should never have trailing white space.
> The best reason is "git blame" to see who wrote the code, i think that makes it clear.

I understand that white space only patches will not be applied.  Will
they be applied if they accompany other corrections?

Also, please address the other questions.

Should I submit patches against simple errors in macro definition
formatting? There are some places where my program catches mismatches
that SOME other compilers might ignore.

There are also some places in the wine headers where macros are
redefined differently from the headers provided by the system or
compilers I have installed. There are also cases where the macros are
defined differently by different wine headers.  Because these problems
may depend on my system configuration, I believe it might not be
possible to simply patch these definitions match the configuration I
have. The problems CAN be fixed simply by adding #undef before each
redefinition, but I think a review of these changes might be in order.
They seem to occur in batches, with none in most headers and multiple
messes in others.

Should I submit each correction as a separate patch, separate patches
accompanying separate bug reports, combined patches for a given header
or combined patch and bug report?

Max