From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7526 invoked by alias); 11 Nov 2010 06:17:25 -0000 Received: (qmail 7506 invoked by uid 22791); 11 Nov 2010 06:17:14 -0000 X-Spam-Check-By: sourceware.org Received: from pool-173-76-56-137.bstnma.fios.verizon.net (HELO cgf.cx) (173.76.56.137) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Thu, 11 Nov 2010 06:17:01 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id BEC7913C061; Thu, 11 Nov 2010 01:16:59 -0500 (EST) Received: by ednor.cgf.cx (Postfix, from userid 201) id B8FAF2B352; Thu, 11 Nov 2010 01:16:59 -0500 (EST) Date: Thu, 11 Nov 2010 06:17:00 -0000 From: Christopher Faylor To: Sebasti?n Puebla Castro , gdb-patches@sourceware.org, Joel Brobecker Subject: Re: [PATCH/Windows] Pass correct environment to a Windows executable started as an inferior Message-ID: <20101111061659.GA6488@ednor.casa.cgf.cx> Mail-Followup-To: Sebasti?n Puebla Castro , gdb-patches@sourceware.org, Joel Brobecker References: <20101108192619.GH2933@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101108192619.GH2933@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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 X-SW-Source: 2010-11/txt/msg00148.txt.bz2 On Mon, Nov 08, 2010 at 11:26:19AM -0800, Joel Brobecker wrote: >Sebastian, > >> This patch fixes a bug found in ports of GDB 7.0/7.1 for Windows: an >> ejecutable started as an inferior doesn't receive its own environment, >> possibly modified, as expected; instead, it inherits the environment >> from current GDB instance. > >Thanks for the contribution, and my sincere apologies for the delay >in getting back to you. It seems that all global maintainers became >super busy all at the same time. > >This change is specific to Windows, and we do have a Windows maintainer. >To have a better chance of attracting his attention, I suggest the use >of "Windows" in the subject. Eg: > > "[RFA/Windows] set environment not propagated to inferior" That really isn't necessary. It already had Windows in the subject. I just missed this the first time around. >This is only a preliminary review, since changes to windows-nat >are normally reviewed and approved by Chris, the Windows maintainer. >However, I noticed a few things that are worth commenting on now: > >> 2010-05-10 Sebasti?n Puebla >> >> ?????????? * windows-nat.c (windows_create_inferior): Create environment >> ???????????? block for new inferior. > >First of all, do you have a copyright assignement on file. In my >opinion, this change is a little too large to be accepted under the >"small change" rule. > >Good job on providing a ChangeLog entry :). > >> RCS file: /cvs/src/src/gdb/windows-nat.c,v >> retrieving revision 1.208 >> diff -c -p -r1.208 windows-nat.c > >Most maintainers here prefer unified diff (diff -u instead of diff -c). >I have a strong preference for unified... Ditto. >Please also consider sending the patch as an attachment rather than >inline your email text, because it appears that your mail swaps spaces >for another weird character, and that makes it impossible to apply your >patch as is. Ditto. >> + #ifdef __USEWIDE >> +?? for(i = 0; !in_env[i]; i++) >> +?? { >> +???? env_size += mbstowcs(NULL, in_env[i], 0) + 1; >> +?? } >> +?? >> +?? env_block = (cygwin_buf_t *) alloca(env_size * sizeof(wchar_t)); >> + >> +?? for(i = j = 0; !in_env[i]; i++) >> +?? { >> +???? j += mbstowcs(&env_block[j], in_env[i], env_size) + 1; >> +?? } >> + #else >> +?? for(i = 0; !in_env[i]; i++) >> +?? { >> +???? env_size += strlen(in_env[i]) + 1; >> +?? } >> + >> +?? env_block = (cygwin_buf_t *) alloca(env_size); >> + >> +?? for(i = j = 0; !in_env[i]; i++) >> +?? { >> +???? len = strlen(in_env[i]) + 1; >> +???? memcpy(&env_block[j], in_env[i], len); >> +???? j += len; >> +?? } >> + #endif >> +?? env_block[j] = 0; >> + > >Several comments: > > - It seems worth putting that code in a separate function. But why > can't we use the in_env array? Is it because of the mbstowcs > conversion in the __USEWIDE case? Ditto on the separate function. > - Curly braces should be omitted if the block is going to have > one statement only. Eg: > > for (i = 0, !in_env[i]; i++) > env_size += mbstowcs(NULL, in_env[i], 0) + 1; > > - Another style gotcha: You need a space before '(' in function calls. Eg: > > alloca (env_size) > > (the same should apply to sizeof) > > - And last but not least: I don't think your code is going to compile > on MinGW (use of "cygwin_buf_t"). Yep. cgf