Hi!

On Fri, 17 Feb 2017 16:45:01 +0000, Pedro Alves <palves@redhat.com> wrote:
> Only noticed this patch now.

Heh, and I've only now gotten back to completing this.  ;-)

> > On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
> > (I'm aware that there is other PATH_MAX usage in GDB sources, which we
> > ought to fix at some point, for example in gdbserver -- which is not yet
> > enabled for GNU/Hurd.)
> > 
> > OK to push the following?  (Similar to Svante's patch in
> > <https://bugs.debian.org/834575>.)
> 
> 
> > 
> > --- gdb/remote.c
> > +++ gdb/remote.c
> > @@ -6927,7 +6927,6 @@ Packet: '%s'\n"),
> >  	  else if (strprefix (p, p1, "exec"))
> >  	    {
> >  	      ULONGEST ignored;
> > -	      char pathname[PATH_MAX];
> >  	      int pathlen;
> >  
> >  	      /* Determine the length of the execd pathname.  */
> > @@ -6936,11 +6935,12 @@ Packet: '%s'\n"),
> >  
> >  	      /* Save the pathname for event reporting and for
> >  		 the next run command.  */
> > +	      char *pathname = (char *) xmalloc (pathlen + 1);
> >  	      hex2bin (p1, (gdb_byte *) pathname, pathlen);
> >  	      pathname[pathlen] = '\0';
> 
> 
> hex2bin can throw, so wrap with a cleanup:
> 
>               char *pathname = (char *) xmalloc (pathlen + 1);
>               struct cleanup *old_chain = make_cleanup (xfree, pathname);
>   	      hex2bin (p1, (gdb_byte *) pathname, pathlen);
>   	      pathname[pathlen] = '\0';
>               discard_cleanups (old_chain);
> 
> OK with that change.

Thanks; pushed to master the attached commit
b671c7fb21306ce125717a44c30a71686bd24db1 "[gdb, hurd] Avoid using
'PATH_MAX' in 'gdb/remote.c'".


Grüße
 Thomas