For what it's worth, my opinion:
A program whose semantics depends on invisible end-of-line
whitespace is erroneous and a disaster waiting to happen.
The portability argument wrt other compilers is all very
well, but the code fails to be portable in so many other
ways, as people have mentioned:
So I assume it is possible for an ISO 9000 environment to allow for ad
hoc sed scripts to fix trivial problems, and it would be the specific
institution, and not ISO 9000, that is broken (IMHO) if anal rule
prevented such utilitarian acts?
ISO9000 is a pretty broad word these days. As someone
Daniel Berlin wrote:
I believe every opinion anyone could ever have about this issue has been
put forth, and nobody on either side has been convinced of anything,
other than that the other side just doesn't get it.
Well the purpose of the discussion here is precisely to see
if there is a conse
On Oct 27, 2005, Robert Dewar <[EMAIL PROTECTED]> wrote:
> When you step out of customs at the Bangkok airport, you see a big
> booth saying "ISO 9000 compliant taxi service" :-)
``Sorry, sir, can't drive you $there, my procedure says I can only take
passengers $elsewhere. I'm afraid the driver
Daniel Berlin wrote:
I'm sorry, did it require 200 emails for people to figure this out?
I'd think that we could have stopped at 10, maybe less.
Instead, everybody just has to throw their opinion on whitespace in,
without bothering to notice someone put forth that opinion 5 minutes
ago.
Not o
Scott Robert Ladd wrote:
Ah! I worked in only one place, a defense contractor, where ISO 9000 was
"followed", and the way management talked, their procedures were
dictated by ISO 9000. So I gather my one experience gave me an
inaccurate view of the subject?
The only sense in which the proc
> So I assume it is possible for an ISO 9000 environment to allow for
> ad hoc sed scripts to fix trivial problems, and it would be the
> specific institution, and not ISO 9000, that is broken (IMHO) if
> any rule prevented such utilitarian acts?
When one of my previous employers went ISO9000, it
So I assume it is possible for an ISO 9000 environment to allow for ad
hoc sed scripts to fix trivial problems, and it would be the specific
institution, and not ISO 9000, that is broken (IMHO) if anal rule
prevented such utilitarian acts?
The question is what does "ad hoc" mean?
Robert Dewar wrote:
It sounds like you are not familiar with ISO 9000 at all :-)
This standard is about following your internal rules, it is not
a set of rules itself, so if you have a rule which prohibits SED
scripts in your environment, this is a rule you have created
for yourself, and you can
> > I believe every opinion anyone could ever have about this issue has been
> > put forth, and nobody on either side has been convinced of anything,
> > other than that the other side just doesn't get it.
>
> Well the purpose of the discussion here is precisely to see
> if there is a consensus f
Much as I agree with your sentiments, in many environments, the use of
ISO 9000 is *required*, as in you don't get the contract if you don't
follow ISO 9000. I have not seen any evidence, personally, that ISO 9000
actually ensures a perfect product, but it is a political requirem
Scott Robert Ladd wrote:
Much as I agree with your sentiments, in many environments, the use of
ISO 9000 is *required*, as in you don't get the contract if you don't
follow ISO 9000.
Actually this is not so common, we have very rarely run into this
requirment. CMM model level is a much more
Scott Robert Ladd wrote:
I'm not familiar-enough with ISO 9000 to judge whether a sed script is
"too great a burden", but I once worked in an environment where writing
a Python script to clean some ugly code got someone (not me) fired for
using an "unauthorized tool", even when the script prod
Bernd Jendrissek wrote:
Also, if a sed script that modifies comments is too great a burden to
bear for such a beaurocracy, then using a different compiler should be
even more of a red-tape jungle. If it isn't, the management system is
broken and you might as well not bother with all those burden
Daniel Berlin wrote:
Which is invariably why it has generated so much discussion.
Surely everyone is familiar with Parkinson's second law (time
spent discussing an issue is inversely proportional to its
importance)
I believe every opinion anyone could ever have about this issue has been
put
On 2005-10-26, Eric Christopher <[EMAIL PROTECTED]> wrote:
> The problem is that it's portable to every other compiler we've
> tested. I am curious what icc and xlc do, but those are the only
> two not tested.
I've just checked icc and it follows the croud (i.e. it treats
"backslash space newline"
Bernd Jendrissek wrote:
My vote: I don't like surprises, and I'd like this code:
int x; // variable x \\
int y; // variable y \\
to do exactly the same as this code:
int x; // variable x \\
int y; // variable y \\
even if that behaviour is not the intent of the programm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 26, 2005 at 03:43:15PM -0700, Eric Christopher wrote:
> >Don't you think it is reasonable to fix horrible coding errors like
> >this, you are just asking for maintenance problems. In the short
> >term, kludging may make sense, in the long t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 26, 2005 at 02:22:55AM -0700, Kean Johnston wrote:
> If you're working in an ISO9000 environment where every single source
> line change is tracked by a rather burdensome process, the last thing
> you want to do is invoke that process for s
On Oct 26, 2005, at 5:55 PM, Joe Buck wrote:
On Thu, Oct 27, 2005 at 01:48:57AM +0200, Vincent Lefevre wrote:
On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
But in a way you are defending it as you want GCC to change. If
there
was any other reason besides ASCII art, some people would be
On Thu, Oct 27, 2005 at 01:48:57AM +0200, Vincent Lefevre wrote:
> On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
> > But in a way you are defending it as you want GCC to change. If there
> > was any other reason besides ASCII art, some people would be more willing
> > to change but there is a
On Oct 26, 2005, at 6:50 PM, Robert Dewar wrote:
The problem is that it's portable to every other compiler we've
tested. I am curious what icc and xlc do, but those are the only
two not tested.
Sorry, I have a different meaning of portable, for me the term is
related to the standard, meaning
On 2005-10-25 21:25:03 -0700, Joe Buck wrote:
> Code that depends on invisible whitespace to function correctly is
> already broken. At some point, someone will do the equivalent of
^^^
> delete-trailing-whitespace and break it.
or some software. I've already
On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
> But in a way you are defending it as you want GCC to change. If there
> was any other reason besides ASCII art, some people would be more willing
> to change but there is a simple fix person's code to get around this issue.
> And that is by not
Eric Christopher wrote:
Don't you think it is reasonable to fix horrible coding
errors like this, you are just asking for maintenance
problems. In the short term, kludging may make sense,
in the long term it sounds a bad idea to keep such
non-portable code around.
The problem is that it's por
>
> >
> > Don't you think it is reasonable to fix horrible coding
> > errors like this, you are just asking for maintenance
> > problems. In the short term, kludging may make sense,
> > in the long term it sounds a bad idea to keep such
> > non-portable code around.
>
> The problem is that it's p
Don't you think it is reasonable to fix horrible coding
errors like this, you are just asking for maintenance
problems. In the short term, kludging may make sense,
in the long term it sounds a bad idea to keep such
non-portable code around.
The problem is that it's portable to every other compi
Stan Shebs wrote:
Again, I think this could be easily addressed in Apple's GCC only,
but that will mean that the software in question will compile on Macs,
but not on GNU/Linux. Of course, having apps on OS X that can't
be ported to Linux is not necessarily a bad thing from Apple's
point of view
Howard Hinnant wrote:
If end-of-line white space is stripped in phase 1, do_thing2() is
called. If end-of-line white space is not stripped, do_thing1() is
called.
SO this is truly appallingly bad code, given its behavior depends
so radically on an implementation defined feature!
Probably
Joe Buck wrote:
On Tue, Oct 25, 2005 at 08:22:15PM -0400, Howard Hinnant wrote:
And it is not my assertion that gcc's behavior is better or worse
than other compilers. Only that gcc's behavior is unique in the
industry (I actually haven't tried all other modern compilers) and
that unique
On Oct 26, 2005, at 1:16 PM, Andrew Pinski wrote:
What I am trying to say is that
the only reason why this was brought up was because of some little
ASCII art (ASCII art does have its place in comments, see rs6000.c for
an example of where ASCII art actually helps). If there was another
reason,
Scott Robert Ladd wrote:
> Robert Dewar wrote:
>> Seems a weak argument to me. Changing gcc would create incompatibilities
>> with previous behavior of gcc, and that is FAR more significant than
>> worrying about other compilers in my opinion. Having gcc compile
>> non-portable code accepted by oth
I don't see either is true here.
Actually, I agree. While I'd like the change to the compiler, I don't
want it to be a switch. Either we do it, or we don't.
-eric
Scott Robert Ladd wrote:
Wouldn't it be possible to implement a compile-time option to enable the
desired behavior only for those poor folk who have this problem?
Of course this is possible, but it is only worth it if
a) there are a substantial number of such poor folk
b) it is not easy for
Robert Dewar wrote:
Seems a weak argument to me. Changing gcc would create incompatibilities
with previous behavior of gcc, and that is FAR more significant than
worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
on
On Wednesday 26 October 2005 18:58, Robert Dewar wrote:
> Steven Bosscher wrote:
> > On Wednesday 26 October 2005 18:28, Joe Buck wrote:
> >>That's what we have standards for: so that compilers work the same way
> >>for standard-conformant code.
> >
> > And we have de facto standards that you just
Dale Johannesen wrote:
Yes. From the user's point of view, the best thing appears to be
treating backslashes in C++ comments as part of the comment,
regardless of what follows them; that seems to follow the principle
of least surprise. That's not standard conforming, and therefore I'm
not advoc
Mike Stump wrote:
Yes. I've asked, how many lines exist that rely upon this, the answer
was zero. We can have someone that has ready access to sourceforge or
the google cache to count there (Hi Matt), to improve the answer, but
my guess is that it would remain fairly low.
of course that
worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
one of low priority compared to maintaining compatibility as far as
possible between gcc versions.
You mean like the change between 2.95 that worked the way Howard
>
> On Oct 26, 2005, at 9:58 AM, Robert Dewar wrote:
> > No, conflicting "de facto" behaviors (certainly not standards), that
> > cannot all be resolved. In this case, we have to worry about past
> > gcc behavior and behavior of foreign compilers.
>
> Yes. I've asked, how many lines exist that r
>
> On Oct 26, 2005, at 9:39 AM, Andrew Pinski wrote:
> > I still am trying to figure out why this was even brought up if it
> > was only due to ASCII art, that seems silly.
>
> sorry ("I find ascii line art silly"); ;-)
>
> We could do that!
That is just stupid, that is infact would be inva
On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:
The problem, I think, is that the behavior of both GCC *and* the
other compilers does not serve the users.
The reason is that there simply isn't any reason why a user would
use a backslash to continue a C++ comment on purpose, and plenty of
reason wh
On Oct 26, 2005, at 9:58 AM, Robert Dewar wrote:
No, conflicting "de facto" behaviors (certainly not standards), that
cannot all be resolved. In this case, we have to worry about past
gcc behavior and behavior of foreign compilers.
Yes. I've asked, how many lines exist that rely upon this, the
On Oct 26, 2005, at 9:39 AM, Andrew Pinski wrote:
I still am trying to figure out why this was even brought up if it
was only due to ASCII art, that seems silly.
sorry ("I find ascii line art silly"); ;-)
We could do that!
If we didn't have any customers or if we expected they wouldn't brin
Steven Bosscher wrote:
On Wednesday 26 October 2005 18:28, Joe Buck wrote:
That's what we have standards for: so that compilers work the same way
for standard-conformant code.
And we have de facto standards that you just want to ignore.
No, conflicting "de facto" behaviors (certainly not s
Howard Hinnant wrote:
Some programmers purposefully put trailing whitespace on their art in
order to prevent translation phase 2 line splicing. And it actually
works everywhere but gcc. Mind you I'm not defending this practice.
I'm just reporting what happens in the field, and giving the
On Oct 26, 2005, at 9:28 AM, Joe Buck wrote:
This is a case of unspecified behavior.
?
That's what we have standards for: so that compilers work the same way
for standard-conformant code.
But in this case, we are talking about the behavior when the
compiler is
given code with *unspecified
>
> On Oct 26, 2005, at 12:18 PM, Robert Dewar wrote:
>
> > Mike Stump wrote:
> >
> >> On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
> >>
> >>> Are you really saying that someone is using ASCII line art in
> >>> comments
> >>> that tweaks this behavior?
> >>>
> >> Yes, I'm sorry if previous mess
On Wednesday 26 October 2005 18:28, Joe Buck wrote:
> That's what we have standards for: so that compilers work the same way
> for standard-conformant code.
And we have de facto standards that you just want to ignore.
Gr.
Steven
On Oct 26, 2005, at 12:18 PM, Robert Dewar wrote:
Mike Stump wrote:
On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
Are you really saying that someone is using ASCII line art in
comments
that tweaks this behavior?
Yes, I'm sorry if previous message didn't make this clear.
Why would line
On Oct 25, 2005, at 11:05 PM, Andrew Pinski wrote:
Why did Apple revert that patch, well because there was push back from
internal developers who did not want to fix their code. Why should
this case be any difference?
I'm sorry you don't understand the differences. In one, we have
every exp
On Wed, Oct 26, 2005 at 08:16:31AM +0200, Steven Bosscher wrote:
> On Oct 26, 2005 02:30 AM, Joe Buck <[EMAIL PROTECTED]> wrote:
> > I'm still waiting for an explanation as to why this is an important
> > issue, other than that someone has a customer who says that it is.
> > Why is it important to
Mike Stump wrote:
On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
Are you really saying that someone is using ASCII line art in comments
that tweaks this behavior?
Yes, I'm sorry if previous message didn't make this clear.
Why would line art ever tweak this problem, why would lines
in such ar
On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
Are you really saying that someone is using ASCII line art in comments
that tweaks this behavior?
Yes, I'm sorry if previous message didn't make this clear.
On Oct 25, 2005, at 9:33 PM, Joe Buck wrote:
Be interesting to see the results of a grep on a large software
base. Does anyone have ready access to, say a linux distro handy?
Of all the hits I know about, none of them were an accident.
You're forgetting something: GNU/Linux distros are built
> Writing sed scripts that change source code is likely to be very
> unpalletable to some users. If you're working in an ISO9000
> environment where every single source line change is tracked
> by a rather burdensome process, the last thing you want to do
> is invoke that process for some source ba
You still have not demonstrated that this is a real problem. If someone
is having a real problem, then we can offer them a simple sed script to
fix it.
If I am recalling the original posting correctly, the fact that
gcc behaves differently to "most other compilers" is the actual
problem. Issues
On Oct 26, 2005 02:30 AM, Joe Buck <[EMAIL PROTECTED]> wrote:
> I'm still waiting for an explanation as to why this is an important
> issue, other than that someone has a customer who says that it is.
> Why is it important to the customer? Why wouldn't a one-line sed
> script that eliminates the is
>
> On Tue, Oct 25, 2005 at 09:46:23PM -0700, Shantonu Sen wrote:
> > You're forgetting something: GNU/Linux distros are built with
> > thousands of lines of patches to support new/different gcc behavior.
>
> Unfortunately, too many C++ programmers in particular never used
> a compiler other
On Tue, Oct 25, 2005 at 09:46:23PM -0700, Shantonu Sen wrote:
> You're forgetting something: GNU/Linux distros are built with
> thousands of lines of patches to support new/different gcc behavior.
Unfortunately, too many C++ programmers in particular never used
a compiler other than g++, and o
You're forgetting something: GNU/Linux distros are built with
thousands of lines of patches to support new/different gcc behavior.
Thousands were added for the 2->3 transition, and thousands more for
3->4. Please don't claim that all upstream programs in all
distributions support gcc 3.4.4
On Tue, Oct 25, 2005 at 06:51:45PM -0700, Mike Stump wrote:
> On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:
> >1) a C++ comment
>
> >But case 1 is the nasty one, as users think they can put anything
> >in a comment. A backslash at the end is likely to be an accident,
> >since just starting the nex
On Tue, Oct 25, 2005 at 07:07:08PM -0700, Mike Stump wrote:
> gcc is free to ignore users, existing code, porting problems from
> other platforms and other C implementations, if we so choose.
You still have not demonstrated that this is a real problem. If someone
is having a real problem, then
On Tue, Oct 25, 2005 at 06:45:55PM -0700, Mike Stump wrote:
> On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
> >I personally like the fact that gcc's behavior does not depend on
> >invisible characters
>
> All other things being equal, this is a nice design goal. I like it
> too. Should we bre
On Oct 25, 2005, at 6:50 PM, Andrew Pinski wrote:
but it is not portable code. That is my point.
I'm sorry, what word/phrase do you mean for code that compiles and
runs on a plethora of actual C++ implementations? Pretend I used
that word/phrase instead.
On Oct 25, 2005, at 6:46 PM, Andrew Pinski wrote:
Hint, hint it was not an accident that this was done.
I am not unaware of the history. What we are addressing is, if this
was a mistake.
On Oct 25, 2005, at 6:43 PM, Andrew Pinski wrote:
In fact the removal of the warning for comment cases was that exact
case
so ...
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00603.html
Curious, the backslash2.c testcase is now:
/* Test warnings for backslash-space-newline.
Source: Neil
>
> On Oct 25, 2005, at 6:45 PM, Andrew Pinski wrote:
> > Does that really matter?
>
> gcc is free to ignore users, existing code, porting problems from
> other platforms and other C implementations, if we so choose. I'm
> not used to writing such factors off wholesale. I tend to think a
On Oct 25, 2005, at 6:45 PM, Andrew Pinski wrote:
Does that really matter?
gcc is free to ignore users, existing code, porting problems from
other platforms and other C implementations, if we so choose. I'm
not used to writing such factors off wholesale. I tend to think a
balance is bet
On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:
1) a C++ comment
But case 1 is the nasty one, as users think they can put anything
in a comment. A backslash at the end is likely to be an accident,
since just starting the next line with a // is easy enough.
Be interesting to see the results of
>
> On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
> > I personally like the fact that gcc's behavior does not depend on
> > invisible characters
>
> All other things being equal, this is a nice design goal. I like it
> too. Should we break peoples otherwise portable code to have an
> imple
>
> On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:
> > I don't think we should change it at all since it is one more thing
> > to break old gcc code like stuff in Linux kernel.
>
> To get concrete, how many times does \ SP SP * NL occur in old/
> current linux kernels?
I was just showing w
Mike Stump wrote:
On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:
I don't think we should change it at all since it is one more thing
to break old gcc code like stuff in Linux kernel.
To get concrete, how many times does \ SP SP * NL occur in old/ current
linux kernels?
$ egrep -r '\
>
> On Oct 25, 2005, at 4:25 PM, Joe Buck wrote:
> > I'm having a hard time picturing source code that
> >
> > a) exhibits different behavior because of this bug, and
> > b) is maintainable (remember, the behavior depends on the presence
> > of characters that are completely invisible to man
On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
I personally like the fact that gcc's behavior does not depend on
invisible characters
All other things being equal, this is a nice design goal. I like it
too. Should we break peoples otherwise portable code to have an
implementation defined b
>
> On Oct 25, 2005, at 4:44 PM, Andrew Pinski wrote:
> > People depending on this is not the correct thing do any ways as
> > there could be another compiler besides which GCC which does this.
>
> Let's enumerate them, what other compilers do this besides gcc?
Does that really matter?
-- Pinsk
On Oct 25, 2005, at 4:44 PM, Andrew Pinski wrote:
People depending on this is not the correct thing do any ways as
there could be another compiler besides which GCC which does this.
Let's enumerate them, what other compilers do this besides gcc?
On Oct 25, 2005, at 4:25 PM, Joe Buck wrote:
I'm having a hard time picturing source code that
a) exhibits different behavior because of this bug, and
b) is maintainable (remember, the behavior depends on the presence
of characters that are completely invisible to many tools).
Perhaps you
On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:
I don't think we should change it at all since it is one more thing
to break old gcc code like stuff in Linux kernel.
To get concrete, how many times does \ SP SP * NL occur in old/
current linux kernels?
On 2005-10-25 17:28:14 -0400, Daniel Jacobowitz wrote:
> I invite you to talk to Thomas about that one; he may well agree.
> That doesn't affect the general case.
I've just seen that it was fixed two years ago. From the ncurses
changelog:
20030719
+ use clr_eol in preference to blanks for bce
On Tue, Oct 25, 2005 at 08:22:12PM -0400, Andrew Pinski wrote:
> Why not get other compilers to change to what GCC does? Why does GCC
> have to follow what other compilers do, maybe other compilers
> would be in the best interest of following what GCC does.
The problem, I think, is that the beha
On Oct 25, 2005, at 8:22 PM, Andrew Pinski wrote:
Why not get other compilers to change to what GCC does? Why does GCC
have to follow what other compilers do, maybe other compilers
would be in the best interest of following what GCC does.
Why not instead get the standard changed and then GCC w
On Tue, Oct 25, 2005 at 08:22:15PM -0400, Howard Hinnant wrote:
> And it is not my assertion that gcc's behavior is better or worse
> than other compilers. Only that gcc's behavior is unique in the
> industry (I actually haven't tried all other modern compilers) and
> that uniqueness in this
On Oct 25, 2005, at 8:11 PM, Joe Buck wrote:
// A poorly formatted comment \\
int x = 0;
int y = 1;
...
Howard,
Have you tested the sequence above with various compilers?
I only know of the results on gcc 4.x, MS, EDG-based, and Freescale
CodeWarrior.
I just
have. The behavior depen
>
> On Oct 25, 2005, at 7:44 PM, Andrew Pinski wrote:
>
> > But this is not an extension at all. This is an implementation
> > defined
> > behavior which is different than what an extension would do.
> >
> > People depending on this is not the correct thing do any ways as
> > there could be an
On Oct 25, 2005, at 7:44 PM, Andrew Pinski wrote:
But this is not an extension at all. This is an implementation
defined
behavior which is different than what an extension would do.
People depending on this is not the correct thing do any ways as
there could be another compiler besides which
On Tue, Oct 25, 2005 at 07:41:11PM -0400, Howard Hinnant wrote:
> I'm not convinced that "extension" is a proper term for this
> behavior. It is more like an incompatibility with the rest of the
> world's compilers. The reason for change is to conform to a de-facto
> standard, and thus ease
Andrew Pinski <[EMAIL PROTECTED]> writes:
| Please read what implemenation defined means, this is what you
| are talking about.
Andrew --
Before taking your time to insult people; please do spend a little
bit of that time on your homework on their background.
-- Gaby
Joe Buck <[EMAIL PROTECTED]> writes:
> I had thought that a numer of users had requested the current
> behavior back in the egcs days, though I can't track down the brain cell I
> stored that info in;
For the record, the current behaviour was implemented here:
http://gcc.gnu.org/ml/gcc-patche
>
> On Oct 25, 2005, at 6:22 PM, Andrew Pinski wrote:
>
> > We have people already complaining about removing extensions. Why
> > should we change
> > this implementionation defined documented behavior.
>
> I'm not convinced that "extension" is a proper term for this
> behavior. It is more
On Oct 25, 2005, at 6:22 PM, Andrew Pinski wrote:
We have people already complaining about removing extensions. Why
should we change
this implementionation defined documented behavior.
I'm not convinced that "extension" is a proper term for this
behavior. It is more like an incompatibili
On Tue, Oct 25, 2005 at 04:05:55PM -0700, Stan Shebs wrote:
> I think you've managed to get everything backwards. We have potential
> customers (dunno if I'm allowed to name them, so I won't) who can't
> use GCC because of its current behavior.
I had thought that a numer of users had requested the
Andrew Pinski wrote:
Oh, one more thing. This seems like the normal problem of not
reading the docs
if something does not work the way you want it to work.
So?
The only thing we can do is point it out that it is documented
behavior and
then move on to the next issue. Also why are we d
As I said, no it is not. A behavior change is only a regression when
the first behavior is correct and the second is not.
Fair enough. :)
-eric
On Tue, Oct 25, 2005 at 03:45:36PM -0700, Eric Christopher wrote:
> >
> >This is not a regression really.
> >
>
> It is a regression against 2.95.
As I said, no it is not. A behavior change is only a regression when
the first behavior is correct and the second is not.
In this case, there is no
On Tue, Oct 25, 2005 at 03:14:27PM -0700, Eric Christopher wrote:
> This is, as Mr. Buck has noted, a regression from 2.95.
No, it is not (and I did not say that); it is a behavior change, which I
vaguely recall was requested.
Still, many of us have to get code past multiple compilers, so the
war
This is not a regression really.
It is a regression against 2.95.
-eric
>
> >
> > Oh, one more thing. This seems like the normal problem of not
> > reading the docs
> > if something does not work the way you want it to work.
>
> So?
>
> > The only thing we can do is point it out that it is documented
> > behavior and
> > then move on to the next issue. Also wh
On Mon, Oct 24, 2005 at 10:07:33PM -0400, DJ Delorie wrote:
>
> > Please name such systems. We can then know to not use them, and can
> > document in the manual they are broken if we wish.
>
> IIRC the Windows cut-n-paste cuts a rectangle, not as-printed.
Yes, to this day, even using their la
>
> >
> >
> > On Oct 24, 2005, at 3:52 PM, Neil Booth wrote:
> >
> > > Howard Hinnant wrote:-
> > >
> > >> I've been reviewing the age-old issue of interpreting
> > >> * as the end-of-line indicator as is the current
> > >> practice with gcc.
> > >
> > > FWIW I support abandoning this behaviour
1 - 100 of 126 matches
Mail list logo
