Re: Oct and Nov 2012

On 31/10/12 14:20, Earnie Boyd wrote:
>> * wsl-20121029-4.patch    Resolves bug #3482704, item #2.
>
> Slight modification to this one, I readjusted the file preamble and
> reset _MINGW_H instead of __MINGW_H.  What was the point of that
> change?

Consistency.  If we accept that the 280 files in the top level include 
directory is a representative sample of the entire corpus of MinGW 
headers, then of these I see:

* 8 which deliberately omit any form of multiple-inclusion guard.

* 248 which derive the name of the guard macro from the file name, in 
accordance with a convention whereby a single underscore is prefixed to 
the file name, case-folded to all-uppercase, and all period characters 
substituted by underscores.

* 20 which adopt this same convention, but then subvert it by appending 
a further trailing underscore.

* 4 which appear to adopt the same convention, but it becomes malformed 
due to (likely typographically erroneous) transposition of characters, 
omission of a character, or insertion of an extraneous character.

In EVERY case, where a guard macro is defined, the convention prefixes a 
leading underscore to the file name, EXCEPT in your modification to 
_mingw.h, which discards it; I merely reverted it to the state which 
prevailed in CVS, (as I can see in my old sandbox, where the macro was 
defined in accordance with the convention, as __MINGW_H).

> I want the file preamble to all look the same anything additional
> goes after the file preamble for consistency.

I can live with this, although I do prefer to see a brief description of 
the purpose of the file, (no more than three lines), at the top, without 
having to search for it below the licensing gobbledy-gook.

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct