From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17920 invoked by alias); 31 Jul 2002 16:32:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17913 invoked from network); 31 Jul 2002 16:32:25 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 31 Jul 2002 16:32:25 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g6VGWJ001124; Wed, 31 Jul 2002 09:32:19 -0700 From: david carlton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15688.4371.193070.843000@jackfruit.Stanford.EDU> Date: Wed, 31 Jul 2002 09:36:00 -0000 To: Andrew Cagney Cc: Daniel Jacobowitz , Tom Tromey , gdb-patches@sources.redhat.com Subject: Re: RFA: >, >>, and "tee" operators In-Reply-To: <3D4758A5.8050605@ges.redhat.com> References: <20020723183956.GA28558@nevyn.them.org> <871y9ub6fj.fsf@fleche.redhat.com> <20020723192325.GA30738@nevyn.them.org> <87d6te8a6o.fsf@fleche.redhat.com> <20020723202051.GA5427@nevyn.them.org> <3D3F5BDF.2050209@ges.redhat.com> <20020725031026.GA20117@nevyn.them.org> <3D401D50.4030009@ges.redhat.com> <20020725161749.GA10862@nevyn.them.org> <3D40371D.6070603@ges.redhat.com> <20020730191825.GA17620@nevyn.them.org> <3D4758A5.8050605@ges.redhat.com> Cc: carlton@math.stanford.edu X-SW-Source: 2002-07/txt/msg00613.txt.bz2 On Tue, 30 Jul 2002 23:25:25 -0400, Andrew Cagney said: >> So in other words, I'd like to stick with >> >>> > redirect [-a[ppend]] FILE [COMMAND] >>> > log [-a[ppend]] FILE [COMMAND] > Don't forget that prefix `-' and `--' are valid C operators. You > can't tell the difference between the above and a valid C > expressions. I think that rules `-...' out. It makes '-...' undesirable, but I don't think it rules it out. Yes, there are situations where what had previously been a legitimate print statement now becomes either a syntax error or, worse yet, remains legitimate but with a different meaning. But I doubt they are all _that_ common, and there is an easy workaround once you're aware of this problem, namely enclosing your expression in parentheses. The reason why I don't think they're all that common is that I don't think that it's all that common to want to print the value of an expression starting with a unary minus. I don't think I'd do that very frequently in everyday interactive use: even if the value that I happen to care about is -something, I'd probably just do 'p something' and negate the answer mentally. I find it easier to imagine printing an expression that begins with a unary minus if that print command is run automatically when hitting a breakpoint, but even there I doubt it would be too uncommon. And, furthermore, it only breaks code where the next character after the unary - is one of the formatting symbols and the character after that is whitespace. (So the fact that '--' is a valid C operator isn't so relevant, because '-' isn't a formatting character. Good thing, too, because I print expressions starting with '--' more often than ones starting just with '-'.) Unfortunately, some of the formatting symbols are common variable names - probably '-x' would be the most common clash - but even so I'm sure that, the vast majority of the time an expression starts with a unary minus, the unary minus is unambiguously part of the expression. And it seems to me that it isn't so big a problem when previously valid print statements become syntax errors: in those situations, the user at least is aware that something's wrong, and can insert parentheses to solve the problem. Situations where previously valid print statements remain valid but have their meaning changed are more problematic; but those are even more rare. Sure, there are some examples - 'p -x - 3' is one (though 'p -x-3' isn't, or 'p (-x) - 3') - but they're not at all common. So I think that, if this syntax is changed, the fact that expressions could start with unary minus signs is going to cause much less grumbling from users than the fact that, once the old p/x syntax gets obsoleted, they'll have to convert over to typing p -x instead. David Carlton carlton@math.stanford.edu