From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id 123923858C78 for ; Wed, 26 Jan 2022 15:49:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 123923858C78 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-x12c.google.com with SMTP id x23so16831951lfc.0 for ; Wed, 26 Jan 2022 07:49:01 -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=SkbWfqNLX8k1setpcNdOJFlHWYc4XlzGv8Md5IRzdCU=; b=YlYNpI8XjfHSAfGaQip7ljO+SURtQFrMWeadQ+k7BqUXEpfugMSXJ7BFfFj/GJD2Wg XKte/WS/LVemU1vsmUvRdWeshaNrU7SXaQ/3ujoUpTLlrBmysE3A+mPXO9DYrot7kFld Lq2xGZv1aLiYgkEpQeS3U6wp4PF9vy0TJm0UHvXU4NyCI59CiTG2HqfGcXqBKrZHz/y6 mQpneWsKMFOrcy6fb+4nFdHbgtOmcSsWkXYrBIfYN71CidEUVp4Fkvih0DfAKh7RUBoF 3xQUk9XbKetTx54/lxXIlhdQrOk0SzpEec6iYgyIb2IFcDETt+AVPTupzgE67mxcfPF9 9YMQ== 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=SkbWfqNLX8k1setpcNdOJFlHWYc4XlzGv8Md5IRzdCU=; b=ofp1iuun3rM4CJSeyankgPN7yJNcUS0A6dr2/aNa2TjdYZRsGmkN2Po4o17ZDwUnHG L3NP5MAzdAjnKHGL+cW4Ktiu+xI3oRSrSa+QRRL2BfWeqmCAyDqM0lH7eANZJYgY7bpR 2R8kSTlrZTg3emaayXwtvmK0TLz3DOrbQb8JUnH/nFx/joQFBavYnS6lricIpjHxFyZ7 Ue+4leMTTZEKo1+WkwgF2dSktVc+T5h0eGwflw26Fw+E5rLWYfbKb8sHrao+UPdFeRKB lcKkdUsVC9kVwNk56GuzgCchFzbQp/0xLa0TTb3qz4NLX26R+CrseF7jG0wSYPyCr3/x uPZA== X-Gm-Message-State: AOAM533acW4G1kAjSU2s85m/N4mMVtybgpkeS6MS9zeKGbA1Ii9OHjAj By3eXrNGJ9LgkVobqN6p5sklcg== X-Google-Smtp-Source: ABdhPJw5FO4NAuY5lsrLuY2C7WVvB1PtySuG4cpUEWCyCIEVC0LqRLPbn6NIc0mbmPxejUVeTqF+4g== X-Received: by 2002:a05:6512:23a5:: with SMTP id c37mr20014352lfv.327.1643212139893; Wed, 26 Jan 2022 07:48:59 -0800 (PST) Received: from [192.168.219.3] ([78.8.192.131]) by smtp.gmail.com with ESMTPSA id h4sm1864625lfv.220.2022.01.26.07.48.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jan 2022 07:48:59 -0800 (PST) Date: Wed, 26 Jan 2022 15:48:56 +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: Message-ID: References: <111e4bb6-d781-ff80-f64b-125ad665f502@web.de> <20220106093322.GD828155@redhat.com> 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 15:49:02 -0000 Hi Simon, Your message wasn't directly cc-ed to me and I missed it previously in the flood of mailing-list traffic. Sorry about this. Please note that I have posted v3 before your message already. > > > I really like the general idea and would like to see this added, but I > > > think the patch goes too far and will break both old and new usage. > > > > I don't understand what "new usage" means here. > > Thanks for checking, that was unclear. With "new usage" I've meant that if > someone temporarily sets the new variable in an extension there is no way to > get back. The "-1 magic value" I've suggested would also allow a temporary > setting outside of "with print characters ". > > That actually reminds me of a documentation question I had: Does the > implementation actually return the amount of characters (especially when the > char array which is printed from has multiple multi-byte characters with > combining symbols)? It does, see the bottom of my message at: . > > > In my opinion there should be only 1 new test for the new setting and > > > the other should be left unchanged while still working, because then > > > existing usages will still work, too. Agreed. > > > 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) > > > > What follows is just my thoughts on what you propose. This work was > > being done for a client of Embecosm's, and Maciej is now driving this > > patch, so what he does is up to him. That said... > > > > I did consider this when I originally wrote the patch. But decided > > against it in the end. > > > > I agree that maintaining backwards compatibility is important. > > :-) 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 I can offer as possible alternative solutions are: * As you proposed, but instead driven by an entirely separate knob such as `set print characters-enable '; if "off", which would also be the default, then keeping the current semantics of `set print elements'. * Leave `set print elements' alone and instead introduce a replacement say `set print array-elements' command for array elements in addition to `set print characters' already have proposed. The latter two commands would adjust the respective settings each while the former command would set them both, for compatibility. It's not clear to me what `show print elements' would have to report however, maybe the `print array-elements' setting. * Have `set print elements' adjust both limits till `set print characters' or `show print characters' have been used, at which point further requests would only adjust the array element limit. This wouldn't pose a problem with `show print elements', but the semantics would be complicated. Thoughts? Maciej