This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: "decorate" gcc extensions with __extension__

Christopher Faylor wrote:
> On Tue, Mar 29, 2005 at 01:52:32PM -0500, Nicholas Wourms wrote:
> You have correctly surmised that both Corinna and I understand what
> pedantic mode is.  You have to take that thought a step further,
> however, and realize that the fact that there is no -pedantic in CFLAGS
> is because we both want to use the full expressive power of gcc without
> worrying if we are complying with ISO C or ISO C++.  This is a conscious
> choice, not an oversight.

I understand that, not many projects do compile at -pedantic by default.
However, you are assuming I am asking you to change huge amounts of code to
conform to ISO standards, which is not what I'm saying.  While I did make some
suggestions regarding variable sized arrays, that was about the limit of the
iso-correctness on my part.  I am not suggesting, in any way, that -pedantic be
added to the default CFLAGS.  And any other changes are going to be trivial,
like nixing a trailing comma in the last member of an enum.

> I thought Corinna's intent was clear in that sentence.  Apparently you
> didn't.
> What she was saying is, for this to be done right, both of us would have
> to be rigorous in the future about making sure that we add decorate
> every extension we use, or, worse, avoid using gcc extensions which
> we've come to rely on.  That would be annoying.

I hear you loud and clear.  I am not suggesting you stop using gcc extensions,
nor would I.  It is true that I made a minor off-the-cuff suggestion regarding
variable sized arrays, but it was intended to be an opinion.

As for the "done right" part, I would point to the other __attribute__ tags
which are used to explicitly mark intentions to the compiler (e.g. unused &&
noreturn).  Looking at the ChangeLog, many of these were added long after the
"offending" initial code was added, mostly likely during a code cleanliness
sweep.  Of course there is no *requirement* for the tags, as code will compile
just fine without them.  The point, however, of using them is to separate the
true-positive warnings from the false-positive warnings.  My intention is no
different.  So why should adding __extension__ be any different?  Just add when
it is noticed/needed, like the other __attribute__ tags are.

> However, if I am correctly interpreting your intent, it sounds like you
> are saying that no one but you would have to worry about sprinkling
> __extension__'s throughout the code and that we could just write code as
> we always do.

Again, I'm not suggesting I be the "point man" on this.  Like other
__attribute__ tags, they can be added as needed/noticed.  It's rather trivial
and I don't see the implied expenditure of labor involved.  You can add them or
not, it won't change the way the code is compiled.  Just think of it like
Rusty's Janitorial patches on LKML.

> If that is the case, then I don't see how it matters if
> we check in your code or not.  You'll constantly be updating things to
> match the latest checkins one way or the other.

Constantly?  I'm afraid I would disagree.  As was stated before, my changes
touch a very small portion of code.  While Cygwin development is lively, it
doesn't come close to most other projects out there.  Frankly, I find the pace
here rather laid-back, which is quite fine IMHO.

> However, if your patches are not going to be checked in,

Well, I had hoped to further discuss this...

> then you don't have to worry about packaging up your changes for cygwin-patches, > which is less work for you.

I know that, I'm not sending patches that I don't want committed.

> Btw, the use of a ?: c is a conscious decision.

Maybe I'm just old fashion and do not like "a ? : c", but I don't understand
why you use it, other than saving a few keystrokes.  Look, aside from the fact
it keeps -pedantic from producing an error, explicitly expanding to "a ? a : c"
makes the code easier to read and the intent more clear.  Just like you could

if (a) b; else c;


if (a)

is more readable.  Wouldn't you agree?  I'm not trying to tell you what to do,
I just think it would be better IMHO.

Look, I understand that you and Corinna see my changes as making extra work for
you.  That isn't my intention and I've tried very hard to make my footprint


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]