On Tue, Nov 01, 2005 at 06:28:21PM -, Dave Korn wrote:
> Per Bothner wrote:
> > Dave Korn wrote:
> >> Per, please. We've been through these ***exact*** interchanges before.
> >> You're now just reiterating the entire thread. You aren't adding
> >> anything new,
> >
> > I didn't see my specif
Per Bothner wrote:
> Dave Korn wrote:
>> Per, please. We've been through these ***exact*** interchanges before.
>> You're now just reiterating the entire thread. You aren't adding
>> anything new,
>
> I didn't see my specific proposal ('\\' follow by space is not a line
> continuation *and* an i
Dave Korn wrote:
Per, please. We've been through these ***exact*** interchanges before.
You're now just reiterating the entire thread. You aren't adding anything
new,
I didn't see my specific proposal ('\\' follow by space is not a line
continuation *and* an improved -Wcomment defaults to on
Per Bothner wrote:
> Joe Buck wrote:
>> So you want the compiler to only consider '\\$" a continuation,
>
> Not my preference, but that is my proposal, in the interest
> of compatibility.
>
>> but to have an unsilenceable warning about '\\ *$'?
>
> Not unsilenceable - but on-by-default. It coul
Per Bothner wrote on 31/10/2005 23:12:02:
> Joe Buck wrote:
> > So you want the compiler to only consider '\\$" a continuation,
>
> Not my preference, but that is my proposal, in the interest
> of compatibility.
^
Compatibility is not an absolute in this case. The two
opposite
Joe Buck wrote:
So you want the compiler to only consider '\\$" a continuation,
Not my preference, but that is my proposal, in the interest
of compatibility.
but to have an unsilenceable warning about '\\ *$'?
Not unsilenceable - but on-by-default. It could be silenced with
an explicit -Wn
On Mon, Oct 31, 2005 at 11:35:45AM -0800, Per Bothner wrote:
> Joe Buck wrote:
> >On Sat, Oct 29, 2005 at 03:45:33AM -0700, Per Bothner wrote:
> >
> >>1. Change the behavior (back) so only '\\$', not '\\ *$', causes a
> >> line to be continued.
>
> >The problem with your item #1 is that there is
Joe Buck wrote:
On Sat, Oct 29, 2005 at 03:45:33AM -0700, Per Bothner wrote:
1. Change the behavior (back) so only '\\$', not '\\ *$', causes a
line to be continued.
The problem with your item #1 is that there is then no way of flagging
code that won't work with the large numbers of produc
On Sat, Oct 29, 2005 at 03:45:33AM -0700, Per Bothner wrote:
> Rather than adding new flags, I'd think I'd prefer:
>
> 1. Change the behavior (back) so only '\\$', not '\\ *$', causes a
>line to be continued.
> 2. Make -Wcomment more useful to it only warns when it might matter:
>The follo
Per Bothner <[EMAIL PROTECTED]> writes:
| Rather than adding new flags, I'd think I'd prefer:
|
| 1. Change the behavior (back) so only '\\$', not '\\ *$', causes a
| line to be continued.
| 2. Make -Wcomment more useful to it only warns when it might matter:
| The following line contains
Rather than adding new flags, I'd think I'd prefer:
1. Change the behavior (back) so only '\\$', not '\\ *$', causes a
line to be continued.
2. Make -Wcomment more useful to it only warns when it might matter:
The following line contains non-comment whitespace.
3. Make -Wcomment the default
On Oct 27, 2005, at 3:48 PM, Gabriel Dos Reis wrote:
| // this is a continued comment \
| // but who cares, because this is a comment too
| % gcc -Wall -c foo.C
| foo.C:1:1: warning: multi-line comment
| Perhaps the thing to do is to fix -Wcomment to eliminate the noise,
| so it will be mor
Joe Buck wrote:
> So the amended suggestion is to fix -Wcomment to shut up about continued
> comments that don't matter, and also to add the new -f option to switch
> the handling of spaces-at-the-end.
I think your proposal, as amended, is the right approach.
I generally don't much like new comm
Joe Buck <[EMAIL PROTECTED]> writes:
| > > -Wcontinued-cpp-comment
| > >
| > > Warn if there is a C++-style comment that is continued by a backslash at
| > > the end of the line, and the following line contains something other
| > > than whitespace and comments. The current setting of
| >
> > -Wcontinued-cpp-comment
> >
> > Warn if there is a C++-style comment that is continued by a backslash at
> > the end of the line, and the following line contains something other
> > than whitespace and comments. The current setting of
> > -f{no-}eol-whitespace-strip is used to decide
I'm good with this proposal. I was against the flag in the first
place for a desire to pick something and let's do that, but it seems
like with so much furor over it we should probably just have a flag. :)
-eric
> -Wcontinued-cpp-comment
>
> Warn if there is a C++-style comment that is continued by a backslash at
> the end of the line, and the following line contains something other
> than whitespace and comments. The current setting of
> -f{no-}eol-whitespace-strip is used to decide what is a co
Daniel was right in that the discussion has degenerated. So, here's
a concrete proposal. Think of it as a start on a documentation patch.
Since there is no consensus, it seems that the right solution is to
have options. I think that the following concept can solve the problems.
-fno-eol-whites
18 matches
Mail list logo
