public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Georg-Johann Lay <gjl@gcc.gnu.org>
To: Joey Ye <joey.ye@arm.com>
Cc: 'Joseph Myers' <joseph@codesourcery.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix PR50293 - LTO plugin with space in path
Date: Sun, 03 Mar 2013 18:43:00 -0000	[thread overview]
Message-ID: <5133995A.1090707@gcc.gnu.org> (raw)
In-Reply-To: <000001ce12f9$0446ab60$0cd40220$@ye@arm.com>

Joey Ye schrieb:
> Ping
> 
>> Subject: RE: [PATCH] Fix PR50293 - LTO plugin with space in path

Does this patch also work with MS-Windows as host, i.e. with \ as path 
separator?

>>>> +static char * convert_white_space(char * orig);
>>> Please fix formatting in many places in this patch to follow the GNU
>>> Coding Standards.  No space after '*', but space before '('; there
>> seem
>>> to
>>> be various other formatting problems as well.
>> My bad. All fixed.
>>
>>>> +/* Insert back slash before spaces in a string, to avoid path
>>>> +   that has space in it broken into multiple arguments.  */
>>> That doesn't seem to be a proper specification of the interface to
>> this
>>> function.  What are the semantics of ORIG?  A string that is a
>> filename,
>>> or something else?  What are the exact semantics of the return value
>> for
>>> quoting - is it correct for the function to convert a (backslash,
>> space)
>>> pair to (backslash, backslash, space) or not?  Is anything special in
>>> the
>>> return value other than backslash and space, and how are any special
>>> characters in the return value to be interpreted?
>>>
>>> As it seems like this function frees the argument (why?) this also
>> needs
>>> to be specified in the comment as part of the semantics of the
>> function.
>> This function might need a string longer than original one to
>> accommodate
>> additional back slashes. So it has to xmalloc a new string. The original
>> string should be freed in such a case. However, it is tedious to caller
>> to figure out that conversion does happens and free the orig. The
>> solution
>> is for this function to free it when conversion happens.
>>
>> By doing so it is required that orig must be allocated and can be freed,
>> as the newly added comments described explicitly.
>>> It would be a good idea for you to give a more detailed explanation in
>>> the
>>> next version of the patch submission of how the path, before the patch,
>>> got processed so that the spaces were wrongly interpreted.  That might
>>> help make clearer whether the interface to this new function is
>> actually
>>> correct, since the subsequent operations on the return value should
>> act
>>> as
>>> an inverse to the operation carried out by this function.
>>>
>>> --
>>> Joseph S. Myers
>>> joseph@codesourcery.com
>> Index: gcc/gcc.c
>> ===================================================================
>> --- gcc/gcc.c	(revision 195189)
>> +++ gcc/gcc.c	(working copy)
>> @@ -265,6 +265,7 @@
>>  static const char *compare_debug_auxbase_opt_spec_function (int, const
>> char **);
>>  static const char *pass_through_libs_spec_func (int, const char **);
>>  static const char *replace_extension_spec_func (int, const char **);
>> +static char * convert_white_space (char *);
>>
>>
>>  /* The Specs Language
>>
>> @@ -6595,6 +6596,7 @@
>>  				    X_OK, false);
>>    if (lto_wrapper_file)
>>      {
>> +      lto_wrapper_file = convert_white_space (lto_wrapper_file);
>>        lto_wrapper_spec = lto_wrapper_file;
>>        obstack_init (&collect_obstack);
>>        obstack_grow (&collect_obstack, "COLLECT_LTO_WRAPPER=",
>> @@ -7005,12 +7007,13 @@
>>  			      + strlen (fuse_linker_plugin), 0))
>>  #endif
>>  	    {
>> -	      linker_plugin_file_spec = find_a_file (&exec_prefixes,
>> +	      char * temp_spec = find_a_file (&exec_prefixes,
>>  						     LTOPLUGINSONAME, R_OK,
>>  						     false);
>> -	      if (!linker_plugin_file_spec)
>> +	      if (!temp_spec)
>>  		fatal_error ("-fuse-linker-plugin, but %s not found",
>>  			     LTOPLUGINSONAME);
>> +	      linker_plugin_file_spec = convert_white_space (temp_spec);
>>  	    }
>>  #endif
>>  	  lto_gcc_spec = argv[0];
>> @@ -8506,3 +8509,52 @@
>>    free (name);
>>    return result;
>>  }
>> +
>> +/* Insert back slash before spaces in orig (usually a file path), to
>> +   avoid being broken by spec parser.
>> +
>> +   This function is needed as do_spec_1 treats white space (' ' and
>> '\t')
>> +   as the end of an argument. But in case of -plugin /usr/gcc
>> install/xxx.so,
>> +   the filename should be treated as a single argument rather than
>> being
>> +   broken into multiple. Solution is to insert '\\' before the space in
>> a
>> +   filename.
>> +
>> +   This function converts and only converts all occurrance of ' '
>> +   to '\\' + ' ' and '\t' to '\\' + '\t'.  For example:
>> +   "a b"  -> "a\\ b"
>> +   "a  b" -> "a\\ \\ b"
>> +   "a\tb" -> "a\\\tb"
>> +   "a\\ b" -> "a\\\\ b"
>> +
>> +   orig: input null-terminating string that was allocated by xalloc.
>> The
>> +   memory it points to might be freed in this function. Behavior
>> undefined
>> +   if orig isn't xalloced or is freed already at entry.
>> +
>> +   Return: orig if no conversion needed. orig if conversion needed but
>> no
>> +   sufficient memory for a new string. Otherwise a newly allocated
>> string
>> +   that was converted from orig.  */
>> +
>> +static char * convert_white_space (char *orig)
>> +{
>> +  int len, number_of_space = 0;
>> +  if (orig == NULL) return orig;
>> +
>> +  for (len=0; orig[len]; len++)
>> +    if (orig[len] == ' ' || orig[len] == '\t') number_of_space ++;
>> +
>> +  if (number_of_space)
>> +    {
>> +      char * new_spec = (char *)xmalloc (len + number_of_space + 1);
>> +      int j,k;
>> +      if (new_spec == NULL) return orig;
>> +
>> +      for (j=0, k=0; j<=len; j++, k++)
>> +	{
>> +	  if (orig[j] == ' ' || orig[j] == '\t') new_spec[k++] = '\\';
>> +	  new_spec[k] = orig[j];
>> +	}
>> +      free (orig);
>> +      return new_spec;
>> +  }
>> +  else return orig;
>> +}

  reply	other threads:[~2013-03-03 18:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-17  2:14 Joey Ye
2013-02-17 22:16 ` Joseph S. Myers
2013-02-18  3:32   ` Joey Ye
2013-03-03 16:48     ` Joseph S. Myers
2013-03-04  8:11       ` Joey Ye
2013-03-06  2:12         ` Joseph S. Myers
2013-02-25  1:41   ` Joey Ye
2013-03-03 18:43     ` Georg-Johann Lay [this message]
2013-03-04  9:03       ` Joey Ye

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=5133995A.1090707@gcc.gnu.org \
    --to=gjl@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joey.ye@arm.com \
    --cc=joseph@codesourcery.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).