From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58362 invoked by alias); 19 Jun 2017 15:30:48 -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 58122 invoked by uid 89); 19 Jun 2017 15:30:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=BAR, states, our, HContent-Transfer-Encoding:8bit X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 15:30:41 +0000 Received: by simark.ca (Postfix, from userid 33) id 897221E4D7; Mon, 19 Jun 2017 11:30:43 -0400 (EDT) To: Pedro Alves Subject: Re: [PATCH v6] C++ify gdb/common/environ.c X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 19 Jun 2017 15:30:00 -0000 From: Simon Marchi Cc: Sergio Durigan Junior , GDB Patches In-Reply-To: <816a5744-b3b4-855c-5f2e-4c9f0d255512@redhat.com> References: <20170413040455.23996-1-sergiodj@redhat.com> <20170619043531.32394-1-sergiodj@redhat.com> <87k248y3zp.fsf@redhat.com> <8aabc6fabb04f4e3e8b08e6fa1b0eacc@polymtl.ca> <816a5744-b3b4-855c-5f2e-4c9f0d255512@redhat.com> Message-ID: <1cff1a8055c0d770fef7171b8394e86d@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.5 X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00517.txt.bz2 On 2017-06-19 16:26, Pedro Alves wrote: > Right, m_environ_vector.clear() is not necessary. > > Note that this move assignment (and likewise the move ctor) leaves the > source vector empty, which violates the "there's always a NULL entry > at the end" invariant. That's OK if the only thing we want to support > of moved-from gdb_environ objects is destroying them, but please do > document that. > > Otherwise, people assuming the standard library's rule, may be > confused/surprised, into thinking that this, e.g., should work: > > gdb_environ env1; > env1.set ("VAR1", "value1"); > gdb_environ env2; > env2 = std::move (env1); // env1 has no NULL terminator after this. > env1.set ("VAR1", "value2); // whoops. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 17.6.5.15 Moved-from state of library types > [lib.types.movedfrom] > > Objects of types defined in the C++ standard library may be moved > from (12.8). > Move operations may be explicitly specified or implicitly > generated. Unless > otherwise specified, such moved-from objects shall be placed in a > valid > but unspecified state. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That's a good point. We should definitely not let the environ object get in an invalid state. Whatever the rule we choose for the terminating NULL, there exists some valid vector states which result in invalid environ states. For example, an environ whose vector contains { NULL, NULL } is not valid. Trying to set an env var in it would give { NULL, "FOO=BAR", NULL }, and that results in an unexpected environment array in the end. Does that mean that after the vector move, we should make sure to leave the moved-from vector in a known state (i.e. clear it, and possible add a NULL), to make sure that we leave our environ object in a valid state?