From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7004 invoked by alias); 28 Apr 2010 17:15:44 -0000 Received: (qmail 6990 invoked by uid 22791); 28 Apr 2010 17:15:42 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Apr 2010 17:15:32 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L1L00400JX6XB00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Wed, 28 Apr 2010 20:15:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.125.239]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L1L00NWJJXS3OC0@a-mtaout20.012.net.il>; Wed, 28 Apr 2010 20:15:29 +0300 (IDT) Date: Wed, 28 Apr 2010 17:15:00 -0000 From: Eli Zaretskii Subject: Re: [python][patch] Add GDB Parameters functionality In-reply-to: <4BD7FD3E.5000802@redhat.com> To: Phil Muldoon Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83fx2fxzut.fsf@gnu.org> References: <4BD592D9.1070801@redhat.com> <838w8ayu7a.fsf@gnu.org> <4BD6D7C7.9040804@redhat.com> <83wrvsyelz.fsf@gnu.org> <4BD73A07.7020706@redhat.com> <83r5m0y9fp.fsf@gnu.org> <4BD7438F.8030508@redhat.com> <83pr1kxoyn.fsf@gnu.org> <4BD7D58B.9020007@redhat.com> <4BD7FD3E.5000802@redhat.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00944.txt.bz2 > Date: Wed, 28 Apr 2010 10:17:50 +0100 > From: Phil Muldoon > CC: gdb-patches@sourceware.org > > In the case of PARAM_STRING (which directly maps to the GDB enum > var_type {var_string} (found in command.h)), the string is parsed one > character at a time. If the character being currently processed equals > a '\', parse_escape (utils.c) is called with the pointer to the string > that points to this character as an argument. The parse_escape > function seems to be called during most output emitted by GDB. In > parse escape, the character after the '\' is fetched, and that > character runs through an a switch. > > If the case is a literal octal, the next two characters are fetched > and converted to the character the octal escape sequence > represents. (i.e. in our example \107 will be translated to 'G') > > If the character is an a,b,f,n,r,t, or v then that character is > returned as '\a', or '\b', or '\f' and so on. This means that in the > string 'Good\tDay', \t will be processed and returned as it is. So C > escape characters are acknowledged and returned intact. Thank you for your effort. In that case, I suggest the following text: @item PARAM_STRING The value is a string. When the user modifies the string, any escape sequences, such as @samp{\t}, @samp{\f}, and octal escapes, are translated into corresponding characters and encoded into the current host charset. (Is it true that GDB encodes into host charset? If not, please modify as appropriate.)