From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5622 invoked by alias); 9 Oct 2010 19:48:28 -0000 Received: (qmail 5604 invoked by uid 22791); 9 Oct 2010 19:48:26 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_05,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 Oct 2010 19:48:20 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P4fOz-0000Fc-7g for gdb@sources.redhat.com; Sat, 09 Oct 2010 21:48:17 +0200 Received: from h86-62-88-129.ln.rinet.ru ([86.62.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Oct 2010 21:48:17 +0200 Received: from vladimir by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Oct 2010 21:48:17 +0200 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Sevenbit-strings only partially respected? Followup-To: gmane.comp.gdb.devel Date: Sat, 09 Oct 2010 19:48:00 -0000 Message-ID: References: <201010092326.36112.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit User-Agent: KNode/4.4.6 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-10/txt/msg00025.txt.bz2 Vladimir Prus wrote: > > I've run into a situation where setting 'print sevenbit-strings' of off still > does not prevent GDB from escaping some characters. Specifically, > consider the character 0xD0, and this bit in printchar: > > if (c < 0x20 || /* Low control chars */ > (c >= 0x7F && c < 0xA0) || /* DEL, High controls */ > (sevenbit_strings && c >= 0x80)) > {/* high order bit set */ > > Apparently, the second condition fires and causes 0xD0 to be quoted. Is > this expected behaviour? Doh. Of course 0xD0 is larger than 0xA0. The value that causes the actual problem is 0x83. Russian letter 'у' is encoded in UTF8 as 0xD1 0x83, and because of the above code, strings with that letter (and some other letters) get messed up completely. Can we please have that (c >= 0x7F && c < 0xA0) clause ripped off? Thanks, Volodya