From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84271 invoked by alias); 19 Jun 2017 16:19:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 84148 invoked by uid 89); 19 Jun 2017 16:19:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 16:19:28 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AF50E80C1D; Mon, 19 Jun 2017 16:19:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AF50E80C1D Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=sergiodj@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com AF50E80C1D Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 874731817C; Mon, 19 Jun 2017 16:19:29 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: Simon Marchi , GDB Patches Subject: Re: [PATCH v5] C++ify gdb/common/environ.c References: <20170413040455.23996-1-sergiodj@redhat.com> <20170616222315.12779-1-sergiodj@redhat.com> <4e43c71a2ac4aa229bb262e18dec668c@polymtl.ca> <87tw3cy5h7.fsf@redhat.com> Date: Mon, 19 Jun 2017 16:19:00 -0000 In-Reply-To: (Pedro Alves's message of "Mon, 19 Jun 2017 14:40:17 +0100") Message-ID: <877f08x84v.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00525.txt.bz2 On Monday, June 19 2017, Pedro Alves wrote: > On 06/19/2017 05:19 AM, Sergio Durigan Junior wrote: > >> I >> think it also makes a lot more sense to always initialize the vector >> with a NULL element, because this means we're correctly dealing with the >> case where there's no environment variable to be passed to the inferior. > > This sentence confuses me, because I don't understand what you mean > by "correctly" here. What was incorrect? What I mean is that the internal state of the vector is correct from the get-go. As you said in another message, the environment vector passed to the exec* family of syscalls should contain at least one element, NULL. This means we can make sure that the vector generated by the API (via the envp method) obeys this rule, or that the internal vector (m_environ_vector) obeys this rule. I prefer the second method, because it leaves everything (internal and external) in a correct state. I don't have any advanced C++ arguments to base my opinion on, and I am well aware that this means preallocating things that maybe didn't need to be allocated, but I still prefer keeping the NULL element there because it makes more sense to me. My half-cent to this discussion. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/