From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6673 invoked by alias); 18 Jul 2006 13:51:17 -0000 Received: (qmail 6662 invoked by uid 22791); 18 Jul 2006 13:51:15 -0000 X-Spam-Check-By: sourceware.org Received: from potter.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Jul 2006 13:51:13 +0000 Received: (qmail 22448 invoked from network); 18 Jul 2006 13:51:11 -0000 Received: from unknown (HELO zigzag.lvk.cs.msu.su) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jul 2006 13:51:11 -0000 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: [PATCH] zero-terminate result of target_read_alloc Date: Tue, 18 Jul 2006 13:51:00 -0000 User-Agent: KMail/1.7.2 Cc: Mark Kettenis , gdb-patches@sources.redhat.com References: <200607181356.16071.vladimir@codesourcery.com> <22754.192.87.1.22.1153228499.squirrel@webmail.xs4all.nl> <20060718133947.GA16064@nevyn.them.org> In-Reply-To: <20060718133947.GA16064@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607181751.06219.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00232.txt.bz2 On Tuesday 18 July 2006 17:39, Daniel Jacobowitz wrote: > Here's a better way to think about the patch, I think. Consider the > result of target_read_alloc to be the contents of a disk file. It > might be an ELF executable or a text README file. The caller knows > which sort of data it is, and will process it appropriately, but > target_read_alloc is just fread in this model. It doesn't know whether > the contents are text or binary. If they are text, why should they > include a terminating NUL in the disk file? > > So with this change, the interface is friendly to consumers which wish > to parse the result as binary data, and also friendly to consumers > which wish to pass it to strcpy or strlen. Yes, I realize my analogy > is a bit flawed in that fread doesn't do this. I think this is quite reasonable analogy. remote packet is just like a fread. packet. target_read_alloc is like some higher-level code, say to read a value from config file, or a read entire file into memory. In both cases, the disk file don't have terminating nulls and you get zero-terminated char*. If target_read_alloc does not zero-terminate data, it requires either manually zero-terminating result, or drag length everywhere. And while it's possible for a remote side to include extra zero byte and increase the size of data by one, that's a fairly uncommon interface, and is likely to result in buggy stubs. - Volodya