From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27692 invoked by alias); 26 Jan 2006 21:05:49 -0000 Received: (qmail 27682 invoked by uid 22791); 26 Jan 2006 21:05:49 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao03.cox.net (HELO eastrmmtao03.cox.net) (68.230.240.36) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jan 2006 21:05:45 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao03.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060126210545.XHXK29285.eastrmmtao03.cox.net@localhost.localdomain>; Thu, 26 Jan 2006 16:05:45 -0500 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1F2EJu-00046b-GQ; Thu, 26 Jan 2006 16:06:18 -0500 Date: Thu, 26 Jan 2006 21:12:00 -0000 From: Bob Rossi To: Mark Kettenis , gdb@sourceware.org Subject: Re: Using XML in GDB? Message-ID: <20060126210618.GA15600@brasko.net> References: <20060126055744.GA29647@nevyn.them.org> <200601262036.k0QKaXJl007966@elgar.sibelius.xs4all.nl> <20060126204812.GA16966@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060126204812.GA16966@nevyn.them.org> User-Agent: Mutt/1.5.9i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00281.txt.bz2 > > > And we get all sorts of things for free; for instance, UTF-8, which will be > > > handy if someone ever wants to include internationalized descriptions in the > > > target description. > > > > > > Does anyone have a good reason why GDB should not make use of this > > > well-standardized format instead of inventing additional ad-hoc formats? > > > > No objection to using a well-standardized format, but that probably > > only makes sense if you're not going to write your own parser. And I > > really would like to avoid making GDB dependent on a library that > > isn't standardly available on all systems we support. > > I definitely have no intention of either writing my own XML parser or > introducing an external dependence. I am tentatively planning to > import one of {expat, libxml2} into src/ and arranging for it to be > built as necessary. Daniel, One limitation I have found using libxml is that it doesn't appreciate you putting certain char's in the file. The NUL char has given me trouble, and has forced me to use conversion to hex or something. Bob Rossi