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 6F6C0385C409 for ; Sat, 8 Jan 2022 16:26:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F6C0385C409 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 j11so27446450lfg.3 for ; Sat, 08 Jan 2022 08:26:38 -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=8+zKGwE1iguUIG06duDzTPQZTk5DCsss1YJpWKFeWRw=; b=AYJ4160CqqC6e8NiubGAcAUulg2Srp278BJCvY6TwOi7xI1Mf4wxQIxCnT4jdlBO+M KaZcvkKdZIM432/KXUZXrLZkV9dodvOMuwFewgJcP564PHgApuQ5gZW6zp6J4L6QAwen T3szlna+uwHkzSomkjFWQnCuRE1CrPebzyKhP43YBG43HYAWN4d5sMawd4m/fqLy3MCq qS/9UJ2UUdBb6w6fInKJM3+kiBrODW+cfkT5Q9pBluoaCR3kb3Ibe83dTlOhSJJoogat I9/ZgrLRcmmJYRRbvk/MI0Xke0WQ3bj/P2qB3xBRVZlJa13ehB7GQfESTp9iMoOaN0Nc AsRw== 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=8+zKGwE1iguUIG06duDzTPQZTk5DCsss1YJpWKFeWRw=; b=B7R+c78KFc7YjlChK0HUALEIZ0B8CYoCHZ3eNHy7bpZSJQdcCn1YmJUiWa3sIHrKFH P+wEMVCkUe9IR2o9J+Q73ia/7/bNz10QJELMETXZAE97Zq1/rhCFX2MWlNlpcuyKGSGI QezwiTzPl6tFmJekmM8SGUl7CFjNk1lFsyEfZe0c+S/fvDkBIridNquGZnpA5n74sc7n 0KBeohQBnXtzQKczKn/XlqBYsMxvgAxS9FZCFFNVjc0R8oxKZ0ShM71YGC3B5NDhZa0Y HXwFFvfwd0qL0/TocaQF+UN5VHkPYgi2MKZSyUMJ7wNZ6PLRXXrNskTvK81GKqLgfflj JDpQ== X-Gm-Message-State: AOAM532YeGXOJUWvXoVv0U00PVCn6FXwmlsTHXf2jEuXaoSpgBAhcjLX tac4amTPbZLuNknNaMJr2YALrQ== X-Google-Smtp-Source: ABdhPJzk2KT1RvBVxVzD/laFnylwn2Bq5pp1aLkQQIoIg5IgthF6hdsrf33nkhq4A8o+IwXVnP7L2w== X-Received: by 2002:a05:6512:450:: with SMTP id y16mr1851545lfk.228.1641659197318; Sat, 08 Jan 2022 08:26:37 -0800 (PST) Received: from [192.168.219.3] ([78.8.192.131]) by smtp.gmail.com with ESMTPSA id s19sm282529lfi.263.2022.01.08.08.26.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jan 2022 08:26:37 -0800 (PST) Date: Sat, 8 Jan 2022 16:26:35 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Burgess cc: gdb-patches@sourceware.org Subject: Re: [PATCH 4/6] Add `set print repeats' tests for C/C++ arrays In-Reply-To: <20211215153313.GL175541@redhat.com> Message-ID: References: <20211215153313.GL175541@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.7 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: Sat, 08 Jan 2022 16:26:39 -0000 On Wed, 15 Dec 2021, Andrew Burgess wrote: > > Add `set print repeats' tests for C/C++ arrays, complementing one for > > Fortran arrays and covering the different interpretation of the `set > > print elements' setting in particular where the per-dimension count of > > the elements handled is matched against the trigger rather than the > > total element count as with Fortran arrays. > > I know we disagree on this topic, but I would, one day, like to see > the C/C++ array printing behave as the Fortran array printing does, as > that makes much more sense to me. I'm not sure if there's much disagreement between us really. I just think there may be use cases, including existing ones, where the C/C++ printer's interpretation is required. It must have been made this way for a reason after all -- if not for one, this code wouldn't have been written in the first place, would it? So what I think we're ultimately after it is a way to switch between the two variants regardless of the language being handled, possibly with the defaults remaining as they are now. > But, adding tests for GDB's current behaviour is definitely a good > thing, so I'm happy to see this going in, with one change... Well, I think we need coverage either way, because otherwise we can't easily see if things continue working the way intended. > Given that the C and C++ tests are almost identical, I think you > should consider just adding one copy in gdb.base and compiling it as > both C and C++. > > For inspiration you can look at these files: > > gdb/testsuite/gdb.base/infcall-nested-structs-c.exp > gdb/testsuite/gdb.base/infcall-nested-structs-c++.exp > gdb/testsuite/gdb.base/infcall-nested-structs.exp.tcl Thanks for the hint. I chose to keep the C++ test in gdb.cp/ as I think it's the way it should be (and any existing mess ought to be cleaned up too) so that say "RUNTESTFLAGS=gdb.cp/*.exp" selects all the C++ testing, but otherwise followed the approach. Maciej