public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Sebasti?n Puebla Castro <spuebla@hotmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH/Windows] Pass correct environment to a Windows executable started as an inferior
Date: Mon, 08 Nov 2010 19:26:00 -0000	[thread overview]
Message-ID: <20101108192619.GH2933@adacore.com> (raw)
In-Reply-To: <SNT110-W553622E76149C966A25851B3900@phx.gbl>

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"

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 <spuebla@hotmail.com>
> 
>            * 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...

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.

> + #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?

  - 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").

I don't think that there is anything cygwin-related to this part, is
there?
      
    
-- 
Joel

  reply	other threads:[~2010-11-08 19:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-05  3:57 [PATCH] " Sebastián Puebla Castro
2010-11-08 19:26 ` Joel Brobecker [this message]
2010-11-11  6:17   ` [PATCH/Windows] " Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101108192619.GH2933@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=spuebla@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).