On Wed, Nov 12, 2014 at 2:59 AM, Jeff King wrote:
>>
>> I do not mind much either way. But I doubt that a single extra struct on
>> the stack will break the bank, compared to the fact that we are forking
>> and execing a new program. I'd also not be surprised if a smart compiler
>> could notice th
On Wed, Nov 12, 2014 at 05:52:29AM -0500, Jeff King wrote:
> > However, my personal taste says that reusing the same memory is more
> > elegant than to waste extra memory unnecessarily, so I will go with the
> > child_process_init() solution.
>
> I do not mind much either way. But I doubt that a
On Wed, Nov 12, 2014 at 11:45:19AM +0100, Johannes Schindelin wrote:
> Okay, I have to say that I was led to believe that reusing the
> child_process struct is okay because argv_array_clear() explicitly
> reinitializes the env_array field, something that is useless churn unless
> you plan to reuse
Hi,
On Tue, 11 Nov 2014, Junio C Hamano wrote:
> Jeff King writes:
>
> > I don't think this is "unfortunately"; freeing the memory was the entire
> > purpose in adding env_array. If you want to easily reuse the same
> > environment in multiple commands, it is still perfectly fine to use
> > "en
Jeff King writes:
> I don't think this is "unfortunately"; freeing the memory was the entire
> purpose in adding env_array. If you want to easily reuse the same
> environment in multiple commands, it is still perfectly fine to use
> "env" directly, like:
>
> struct argv_array env = ARGV_ARRAY_I
On Mon, Nov 10, 2014 at 03:41:09PM +0100, Johannes Schindelin wrote:
> > However, start_command() will set "env" to env_array.argv only if "env"
> > was unset to begin with, and if it was already set, the caller will need
> > the original value. Therefore, we need to be very careful only to reset
On Mon, Nov 10, 2014 at 01:44:24PM -0800, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > In start_command(), unset "env" fields are initialized via "env_array". In
> > finish_command(), the "env_array" is cleared, therefore the "env" field
> > will point to free()d data.
> >
> > Howev
Johannes Schindelin writes:
> In start_command(), unset "env" fields are initialized via "env_array". In
> finish_command(), the "env_array" is cleared, therefore the "env" field
> will point to free()d data.
>
> However, start_command() will set "env" to env_array.argv only if "env"
> was unset
Hi,
On Mon, 10 Nov 2014, Johannes Schindelin wrote:
> In start_command(), unset "env" fields are initialized via "env_array". In
> finish_command(), the "env_array" is cleared, therefore the "env" field
> will point to free()d data.
>
> However, start_command() will set "env" to env_array.argv o
In start_command(), unset "env" fields are initialized via "env_array". In
finish_command(), the "env_array" is cleared, therefore the "env" field
will point to free()d data.
However, start_command() will set "env" to env_array.argv only if "env"
was unset to begin with, and if it was already set,
10 matches
Mail list logo
