From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 8F2B2385B81D for ; Wed, 26 Jan 2022 18:18:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8F2B2385B81D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-lf1-x132.google.com with SMTP id o12so496342lfg.12 for ; Wed, 26 Jan 2022 10:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=MJthLf7S1MXBq/f8P8z5StlxWRBV/qDVWF8LXI2nTT0=; b=QjIJ8njOZptgkpLBrSW02CtxYAtWUpomTBREWr08yznLZm3UdvSCxZyH9lTMlc3aEc SbrLCLj5mmP/SYqKAA0LLpvbgQON9EZVq5MGy/NBLSLgSm+D2BKtNrl4CgCj0+FTrNai t18TDB2CO5JjSfBQWSQDw7tiM3nu4bPtNOLEswtGv8nrni+jO2IUfQhvyC3a3A/sAFde O16NSKkysQ+ETrGanociSZQaynPzv81F5b7n7yi5fBltHESsQjn8jkLBQPsrFJbwfJkq Ggf7Yo4GIdzT9f1x+AnGBySaoeQk9+6LNCQbA37CjEjmEGXmByC629nEOy/BdOnao6Wg Preg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=MJthLf7S1MXBq/f8P8z5StlxWRBV/qDVWF8LXI2nTT0=; b=teHld5gpMdpKwuhHWlcVN+dQ3PlwRWdCe1c8VmbLYXuD3HQGPgIkdJdew/dJs6a333 Nm+0QMRdAcbD6vRj9LYtxSeeJCqpd3sEId6IsUF5OdIp/xgHFf0YwELhKH+GkjQH/B8b xqInihdWJjvSnRtB3V9RlFHKvK9OO0SPZ4BLcuY976heXIqEyEilwmHoePeDeZQK7kB8 UFKTBxp9smyS28n6MqwCo/ITea2vMPzEHgbMcgCn4giUqq1kJA0OT5ppzcp/lomI9Uni cysQomsD+du9ix1gzd/JwK5VUvEoCuzNBMc1Ht4gJeTp46lTRvGX9bKJkQWaO1JDwCer 380w== X-Gm-Message-State: AOAM530AG3Z4uMg2CaqTMk/5ae856SZbzL/NrY6qubkUpsGKwYqsb4HQ zsZm4b9f0sCabVrQwzsYOtC2xQ== X-Google-Smtp-Source: ABdhPJzM5NYaeKGrSlowfotFuCB0fFJiEvJVmHBT3U3iU/UIxP2p4XbmbYzPsmapUveax2oIJkv7SQ== X-Received: by 2002:ac2:5a44:: with SMTP id r4mr75047lfn.81.1643221120424; Wed, 26 Jan 2022 10:18:40 -0800 (PST) Received: from [192.168.219.3] ([78.8.192.131]) by smtp.gmail.com with ESMTPSA id o17sm15982lfu.180.2022.01.26.10.18.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jan 2022 10:18:39 -0800 (PST) Date: Wed, 26 Jan 2022 18:18:37 +0000 (GMT) From: "Maciej W. Rozycki" To: Simon Sobisch cc: Andrew Burgess , gdb-patches@sourceware.org Subject: Re: [PATCH v2] gdb: split array and string limiting options In-Reply-To: <6d92837c-ffe1-dbf3-bf61-15ecbcc140ea@gnu.org> Message-ID: References: <111e4bb6-d781-ff80-f64b-125ad665f502@web.de> <20220106093322.GD828155@redhat.com> <6d92837c-ffe1-dbf3-bf61-15ecbcc140ea@gnu.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 18:18:43 -0000 On Wed, 26 Jan 2022, Simon Sobisch wrote: > > > > > To do so the new parameter cannot be directly used as it is in the > > > > > patch > > > > > but must be fowarded to a new function or duplicated. > > > > > > > > > > As an example this would mean instead of : > > > > > > > > > > --- src.orig/gdb/c-valprint.c > > > > > +++ src/gdb/c-valprint.c > > > > > @@ -271,7 +271,7 @@ c_value_print_array (struct value *val, > > > > > > > > > > for (temp_len = 0; > > > > > (temp_len < len > > > > > - && temp_len < options->print_max > > > > > + && temp_len < options->print_max_chars > > > > > && extract_unsigned_integer (valaddr + temp_len * eltlen, > > > > > eltlen, byte _order) != 0); > > > > > ++temp_len) > > > > > > > > > > have the following > > > > > > > > > > > > > > > + const int print_max_chars = (options->print_max_chars != -1) ? > > > > > options->print_max_chars : options->print_max; > > > > > for (temp_len = 0; > > > > > (temp_len < len > > > > > - && temp_len < options->print_max > > > > > + && temp_len < print_max_chars > > > > > && extract_unsigned_integer (valaddr + temp_len * eltlen, > > > > > eltlen, byte_order) != 0); > > > > > ++temp_len) > > > > > > Proposal 1 - Should work, shouldn't it? > > > If you want to keep backwards compatibility, then no particular value for > > `set print elements' can be used to drive `set print characters' I'm > > afraid. Someone may have used it somewhere. > > What do you mean with that? If the default is whatever print elements is it > should be compatible, shouldn't it? Right, I got this mixed up as it's the new `set print characters' setting that will drive the default rather than the existing `set print elements' one, the semantics of which will remain unchanged for non-character entities. So e.g.: (gdb) set print characters elements (which will also be the default) will make `set print elements' drive the number of characters printed (and the `elements' syntactic argument can either set the limit to a reserved value such as `-1' as you suggested or drive a separate internal boolean flag). While if we use any other value, then the character limit will get separated from the `set print elements' setting. So it seems good to me and probably the least interface complication for users and the least maintenance burden to carry along. Thank you for your persistence! Any other input, anyone? Maciej