From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8383 invoked by alias); 19 Jan 2014 18:10:50 -0000 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 Received: (qmail 8373 invoked by uid 89); 19 Jan 2014 18:10:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 19 Jan 2014 18:10:48 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MZN00700UG1W600@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Sun, 19 Jan 2014 20:10:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZN007MXUHWLBA0@a-mtaout20.012.net.il>; Sun, 19 Jan 2014 20:10:44 +0200 (IST) Date: Sun, 19 Jan 2014 18:10:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH v1 02/36] Guile extension language: doc additions In-reply-to: To: Doug Evans Cc: ludo@gnu.org, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83sisjj105.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <52b9da59.64ab440a.0b0b.7e1c@mx.google.com> <83ha9w68av.fsf@gnu.org> <87sit4kb1t.fsf@gnu.org> <83eh4ow78t.fsf@gnu.org> <87k3egez8e.fsf@gnu.org> <87mwitovvh.fsf@gnu.org> <83wqhvj4bw.fsf@gnu.org> <83txczj2o2.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00723.txt.bz2 > Date: Sun, 19 Jan 2014 09:53:21 -0800 > From: Doug Evans > Cc: Ludovic Courtès , > "gdb-patches@sourceware.org" > > > For C-like languages, a value is a string if it is a pointer to or an > > array of characters or ints of type @code{wchar_t}, @code{char16_t}, > > or @code{char32_t}. For other languages ... [say here how string > > values are distinguished in other languages]. If the string is > > terminated by a zero of the appropriate width, it will be converted up > > to that zero. For strings that are not zero-terminated (which > > includes strings in non C-like languages), you must specify the length > > for conversion. > > Even in C-like languages the user may wish to specify a length. > > E.g., C++ strings have a length, but it's up to the library to specify how it's > recorded. Plus C++ programs can have multiple string implementations > (not just std::string). Not always ideal, but an app may have a specific > performance issue for a specific part of it and thus provides its own > string implementation for that part. Thus in this (important) case there > is no text I can provide here to answer the question you are asking. > > Plus there's a maintenance issue of describing how each language > defines a string. We don't want to have to update this part for each > new language. Fair enough. How about the following variant, which is entirely agnostic to the language? Values are interpreted as strings according to the rules of the current language. If the optional length argument is given, the string will be converted to that length. Otherwise, for languages where the string is zero-terminated, the entire string will be converted. If you want to say something about C-like languages, we can have a "for example" sentence after the 1st one. Something like For example, in C-like languages, a value is a string if it is a pointer to, or an array of, characters or ints of type ... > Please can I keep the current text? If you think it is better than what I suggested above.