From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id E1D05384F49F for ; Thu, 24 Nov 2022 11:38:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1D05384F49F 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-wr1-x42a.google.com with SMTP id s5so2102735wru.1 for ; Thu, 24 Nov 2022 03:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7NPcbCiLRWQvY4rd53xBaiRnqu9KJFNKTlifpyHt41k=; b=LQA4aWz2yFbfyRjAr0zDg857tJz5wQGSXvF/4yrKX74WAHjAF3GNbSNbms7Zpj7IaF Z1BXtbElQ1ADi87StFQBpSRjPannC/hZ+VqmHgK6qmdyakeridxRFIlQaYpTPQ0eXJ4y cfCHqHlXgHm7cIv3XGnmrb7JVnWBQ3bXbDmiCGzVwvoT01bRFTrIwazhdF7Zc/9l+uev UXRVk2xRocs0ooG//UtuSJBCIJZJexzoSJlIlRICtpJrOvHXB92JRFOxHpNOvKaRQWfw PdkjQDWiebKkZs19ZBK84wilP+HwZO+3sNR/TkZkT/eJUHqdP37CEoSwJhjVIZdbwGSM Nj4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7NPcbCiLRWQvY4rd53xBaiRnqu9KJFNKTlifpyHt41k=; b=60c+EfYsAv7wUBfMsMDE7DmV6AswRz9QIJh/8yUujjHHPtO9OZP2NbsqP95C3pXK8u iihsV43jhlHT8NeuI8DE2//0c0lcEKeY/qHuRAYyHxW1SA70pU3F90fg/QSl1gDajSsA Z03XA75e88TDzHlIKJqzsgvI5X1CXI4wbaHEufiCdf0aR/2ec1AXFIPn8JlxV/yNIEPz mZcgeGTiRRduAhdwriABlo+yRit0H2rKjbiYeluUnWh/0KxtI7xrAg8Cc/SnSnJSu9H5 H3tBftFUO0wpE3wYi8CrB/An0/UhOWtVytbtldvCZ0Ox/ZxGjbw2JIa6hqWRqF+5bSxt MdCQ== X-Gm-Message-State: ANoB5plV7vCT6CyJgkaL6UvJX6d+wQ78+gwqsHJao2UooEYx2qH1ywdD QXcuARfIjNQMSaXDNNIb5xirog== X-Google-Smtp-Source: AA0mqf7EXgh3I99KJxsw6BTPnGy2lq4OxkHRFF8VnbMUtt3oUP60ih80FglkWqRBdWWzMQ0eV0nxtQ== X-Received: by 2002:adf:eb03:0:b0:241:f52d:cac9 with SMTP id s3-20020adfeb03000000b00241f52dcac9mr3911931wrn.591.1669289888751; Thu, 24 Nov 2022 03:38:08 -0800 (PST) Received: from tpp.orcam.me.uk (tpp.orcam.me.uk. [2001:8b0:154:0:ea6a:64ff:fe24:f2fc]) by smtp.gmail.com with ESMTPSA id e14-20020adfe7ce000000b00241e7007905sm1130505wrn.75.2022.11.24.03.38.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2022 03:38:08 -0800 (PST) Date: Thu, 24 Nov 2022 11:38:06 +0000 (GMT) From: "Maciej W. Rozycki" To: Simon Marchi cc: Simon Marchi , gdb-patches@sourceware.org, Simon Sobisch , Tom Tromey Subject: Re: [PATCH v7 2/4] GDB: Allow arbitrary keywords in integer set commands In-Reply-To: <146021e6-41cb-22d3-6cec-06aed5818867@simark.ca> Message-ID: References: <03f4f878-6423-e905-d65c-7a4e9aa45490@polymtl.ca> <146021e6-41cb-22d3-6cec-06aed5818867@simark.ca> 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.5 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 31 Oct 2022, Simon Marchi wrote: > >> The "p" in `var_pinteger' stands for "positive", for the lack of a more > >> appropriate unambiguous letter, even though 0 obviously is not positive; > >> "n" would be confusing as to whether it stands for "non-negative" or > >> "negative". > > > > We don't have to restrict ourselves to a single letter. By the end of > > reading the commit message, I had already forgotten what the `p` stood > > for. Ideas: > > > > - var_non_negative_integer > > - var_zero_or_positive_integer > > - some better suggestion After the switch to C++ our code has already become over-indented and overly line-wrapped and therefore hard to read. Making identifiers longer than absolutely necessary only makes things worse in my opinion. > > On the other hand, is there any reason why "pintegers" couldn't be > > stored as var_uinteger, with the proper literal_def? With `var_uinteger' there's no way to prevent values in the range of (INT_MAX; UINT_MAX] from being used. I think implementing an explicit way to exclude this range via a special `literal_def' entry would be an overkill. > I forgot: I didn't have significant comments on the code itself. Maybe > the only strange thing is the fact that you pass the list of extra > literals in the erased_args structure. I don't think it should be > there, it's not something that need to be type-erased (cast to void). I have adjusted code accordingly then. Thank you for your review. Maciej