From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1708 invoked by alias); 1 Aug 2002 17:24:57 -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 1701 invoked from network); 1 Aug 2002 17:24:56 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 1 Aug 2002 17:24:56 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g71HOsM02471; Thu, 1 Aug 2002 10:24:54 -0700 From: david carlton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15689.28390.400986.70448@jackfruit.Stanford.EDU> Date: Thu, 01 Aug 2002 10:24:00 -0000 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: >, >>, and "tee" operators In-Reply-To: <3D494E38.3080106@ges.redhat.com> References: <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> <15688.4371.193070.843000@jackfruit.Stanford.EDU> <20020731163628.GA5436@nevyn.them.org> <3D494E38.3080106@ges.redhat.com> Cc: carlton@math.stanford.edu X-SW-Source: 2002-08/txt/msg00005.txt.bz2 On Thu, 01 Aug 2002 11:05:28 -0400, Andrew Cagney said: [ In response to my comment that the 'print -x EXPRESSION' syntax didn't break many cases and those case could be fixed with adding parentheses. ] > There is an old rule ``KISS''. At some point there are too many > workarounds and edge cases and they are arising too frequently. Yes, that's true. But keeping things simple has several implications here: 1) Option syntax should be uniform between programs. 2) Option syntax should be uniform within a single program. 3) Option syntax should be chosen so as to make it clear when something is an option and when something isn't. Point 1) suggests that option syntax should start with -. (Or perhaps with - in a Unix environment and / in other appropriate environments.) Point 2) suggests that all options should start the same way. Point 3) suggests that option syntax shouldn't start with -. (Incidentally, are there programming languages in which / can be a unary operator? Not that I'm suggesting we should seriously worry about that, I'm just curious.) But, as we've all noticed, these are incompatible. Daniel suggests that bending 2) to the extent that GDB does is acceptable. I suggest that bending 3) might be acceptable, or at any rate isn't clearly less acceptable than bending 2). I'm not sure which one you want to bend, or if you see another way out of this problem; you seem strongly against bending 2) or 3), but I doubt that bending 1) would make too many people happy either. > To consider a working example, the MI uses ``-''. The syntax is loose > enough to allow humans to enter free form commands vis: > -mi-command -opt optarg param > However, client programs should always generate commands using the more > robust form: > -mi-command -opt "optarg" -- "param" > (always include ``--'', encode all parameters as quoted strings.) Indeed. And I claim that programs that need to use the print command in a robust way could simply do print (EXPRESSION) rather than print EXPRESSION As you say, this adds another special case to consider; I agree that this is unfortunate, and would be avoided in a perfect world. > BTW, simply adding paren around an expression doesn't really help. > GDB often parses expressions and files using ``strchr(' ')''. That > means that things like: > EXPRESSION: ("foo bar") > FILE: "/a b/c" > do not get handled correctly. I'm admittedly not an expert about how GDB parses expressions, but I don't really see the relevance here. I'm not claiming that adding parentheses will solve other existing problems with the GDB parser; but are there really situations where GDB would parse EXPRESSION correctly but (EXPRESSION) incorrectly? (Here, by EXPRESSION I mean "expression in the language that we're debugging", of course.) I can't reproduce the problem you mention above: (gdb) p "foo bar" $2 = "foo bar" (gdb) p ("foo bar") $3 = "foo bar" (gdb) p ("foo bar"[4]) $4 = 98 'b' but I would imagine that, if there are situations where GDB handles ("foo bar") incorrectly, it would also handle "foo bar" incorrectly. Of course, this is all a bit academic now: it seems that people agree that, for commands that take filenames, using - to start options is reasonable, which answers the immediate question that started the thread. David Carlton carlton@math.stanford.edu