From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by sourceware.org (Postfix) with ESMTPS id BF840396E074 for ; Thu, 2 Jun 2022 14:31:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BF840396E074 Received: by mail-io1-xd2f.google.com with SMTP id n145so4969323iod.3 for ; Thu, 02 Jun 2022 07:31:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=AMSfPRFyOc9VEHa8YbeKAYEQ4+8GHbRvJme7pldty0Y=; b=V5gJ/NJoitmQxANCN4KAcUYd7ueoVt3Tl0SwfUCVtCyT5pSQyyo6i/s2WvOspk03lH 9qInQvBcgeepvhvzDjzy+7lCwL08i7hi+3uswElUmQbQ4xwieA1lcUrGqcjPshGTSDay JgB0BCsRbk4b4PHiJI8pgvLZ19XxDrIGNo2/p2KTkODPzR40I8N9krF+lv+gQsU3QI1f x97HT6EL898K/cq2g/fYg1CBaeZ+9o4RQ7WEILyE7yByi0I6mIORg7o3CgbLkbNaxojO FP6HMLsDLYSOWaR18jGmGBTeK8/CiJiXMTwtRliw8o+/Lg2Xyry0nzmeC+FQdo5K9YlU bDTA== X-Gm-Message-State: AOAM532iIxHFUmelSqcKysiQ3HaF/n4Lh1vhduTb8iuKOjt1Vu5O43jv bIoix/Qg+E0JPmyIpgpCmWQB1w== X-Google-Smtp-Source: ABdhPJwcwsye/hHEhDypmXhr5SJsvWEAXfXB1k+AGXwSCKjs9IKC8szPyGjTwhFhCNg5Ntb+nDeQvg== X-Received: by 2002:a05:6602:2e94:b0:669:1be1:1ac7 with SMTP id m20-20020a0566022e9400b006691be11ac7mr717225iow.213.1654180288057; Thu, 02 Jun 2022 07:31:28 -0700 (PDT) Received: from murgatroyd (71-211-167-178.hlrn.qwest.net. [71.211.167.178]) by smtp.gmail.com with ESMTPSA id k9-20020a02cb49000000b0032e25ae66b9sm437280jap.81.2022.06.02.07.31.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jun 2022 07:31:27 -0700 (PDT) From: Tom Tromey To: Ilya Leoshkevich Cc: Tom Tromey , Andrew Burgess , Pedro Alves , Andreas Arnez , gdb-patches@sourceware.org Subject: Re: [PATCH 1/5] gdbsupport: Introduce obstack_newvec References: <20220602133546.2948282-1-iii@linux.ibm.com> <20220602133546.2948282-2-iii@linux.ibm.com> X-Attribution: Tom Date: Thu, 02 Jun 2022 08:31:26 -0600 In-Reply-To: <20220602133546.2948282-2-iii@linux.ibm.com> (Ilya Leoshkevich's message of "Thu, 2 Jun 2022 15:35:42 +0200") Message-ID: <87czfr3znl.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.4 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 02 Jun 2022 14:31:30 -0000 >>>>> "Ilya" == Ilya Leoshkevich writes: Ilya> obstack_calloc() allocates multiple objects, but doesn't call their Ilya> constructors. obstack_new() allocates a single object and calls its Ilya> constructor. Introduce a new function that does both. Is there some reason you want to keep these objects on the obstack at all? There's no requirement to do that in gdb, and it's probably simpler to just use ordinary C++ allocation instead. Tom