From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6955 invoked by alias); 18 Jul 2006 19:51:20 -0000 Received: (qmail 6945 invoked by uid 22791); 18 Jul 2006 19:51:20 -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 19:51:18 +0000 Received: (qmail 8719 invoked from network); 18 Jul 2006 19:51:16 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jul 2006 19:51:16 -0000 To: Vladimir Prus Cc: Daniel Jacobowitz , Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [PATCH] zero-terminate result of target_read_alloc References: <200607181356.16071.vladimir@codesourcery.com> <22754.192.87.1.22.1153228499.squirrel@webmail.xs4all.nl> <20060718133947.GA16064@nevyn.them.org> <200607181751.06219.vladimir@codesourcery.com> From: Jim Blandy Date: Tue, 18 Jul 2006 19:51:00 -0000 In-Reply-To: <200607181751.06219.vladimir@codesourcery.com> (Vladimir Prus's message of "Tue, 18 Jul 2006 17:51:04 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00238.txt.bz2 Vladimir Prus writes: > 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. Another way to look at it is to say that target_read_alloc clearly operates on blocks of uninterpreted bytes --- it returns address and length, after all --- but the interface as given requires users retrieving text that they'd like to process as null-terminated strings to make an extra copy. The change to the interface Vlad's proposed would make the copy unnecessary. Of course we can't accomodate every random string representation anyone could come up with; we can't avoid copies in every case. And it's not our job to do so. But null-termination is a common need, and one actually at hand. Examples from elsewhere: in Guile, even though our strings could contain arbitrary binary data, we also included an extra null byte at the end, beyond the official length of the string, so that C code that knew it was working with text (filenames, for example) could simply use the string contents in place, without needing to make a null-terminated copy.