From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cXnMJo7HHmFkGwAAWB0awg (envelope-from ) for ; Thu, 19 Aug 2021 17:05:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 871021EDFB; Thu, 19 Aug 2021 17:05:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D1C241E4A3 for ; Thu, 19 Aug 2021 17:05:16 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4B7D239AE001 for ; Thu, 19 Aug 2021 21:05:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4B7D239AE001 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629407116; bh=9PW9OMhY7/J+OKKAQeqck3j7Rxuyodo36N8uldgfV8E=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=I+26KAcWnXnoz/ZbWNEECVeCB0FZfQVck1GX+FS/Y8FTBG5eoJaFNrfKqZYfodlqX ImvW8nglU+oyAdF3JEKpfNGkgz7gYhLZIkFJVBNHUWscJ4GN95hR/8hxbP8iB3mUc6 PSrRNb/Jt/zw/55bZ9d8Ke+ZefwnnPElSopFIKoQ= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 6265239AE01B for ; Thu, 19 Aug 2021 21:04:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6265239AE01B Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 17JL3XI7030454 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 17:03:39 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 17JL3XI7030454 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 09BD81E4A3; Thu, 19 Aug 2021 17:03:33 -0400 (EDT) Subject: Re: [PATCH v2 3/4] gdb: Have setter and getter callbacks for settings To: Lancelot SIX References: <20210808192302.3768766-1-lsix@lancelotsix.com> <20210808192302.3768766-4-lsix@lancelotsix.com> <727ab80a-c72d-960a-6d6e-a731aaa147dd@polymtl.ca> <20210810221852.bqbb6opnrlaqgob5@Plymouth> <7de0a03d-77bf-3b09-9a11-4a109afce8a8@polymtl.ca> <20210811195946.ls3e2d2sbpt24o2e@ubuntu.lan> Message-ID: <435b5531-5f62-d28d-9cef-c5756e8f014e@polymtl.ca> Date: Thu, 19 Aug 2021 17:03:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210811195946.ls3e2d2sbpt24o2e@ubuntu.lan> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 19 Aug 2021 21:03:33 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2021-08-11 4:00 p.m., Lancelot SIX wrote: >> Another option would be to use >> >> gdb::optional var; >> >> in cmd_list_element, and make it such that a setting can never exist in >> an invalid state. Two constructor would exist, one to construct a >> setting with a pointer to a buffer and another with the setter/getter. >> There would be no need (I think) for set_p and set_accessors. > > This approach would be a problem within param_smob > (gdb/guile/scm-param.c). This struct is memset initialized, so we cannot > have one of its member which is not a PODType (see the redefinition of > memset in gdbsupport/poison.h). We could have a pointer to a properly > constructed setting within a param_smob plus some manual memory > management, but I am not sure it is worth it. Tony Tye sent me some comments about this patch, which made me reconsider the approach a bit. I don't see the problem with Guile / param_smob. In your patch, setting_wrapper is just a transient object, it exists just for a moment to make the glue between a setting (which can be handled by the common command code) and a param_smob. But it never needs to be stored anywhere (in a POD type or otherwise). I implemented this approach of using gdb::optional and constructors, and it seems to work pretty well. I prefer it, because, as mentioned before, the setting object can't exist in an invalid state. And that is one less thing to worry about. The other comment was that the unions setting_getter and setting_setter plus all the get_setting_setter / get_setting_getter implementations were not really needed but add a lot of code. Tony suggested to save the getter and setter function pointers to type-erased variables, just like we do for m_var. And I don't think we lose any safety, as var_type_uses already validates that we don't pass some invalid type T, and that T matches var_type. That removes a lot of boilerplate. I implemented this, and stored the getters / setters as `void (*) ()`. Storing them as `void *` wouldn't work, because you can't freely convert function pointers to data pointers and vice versa. I started from your users/lsix/refactor-typesafe-var, made changes to the various patches, and uploaded it to users/simark/refactor-typesafe-var. Let me know what you think. Simon