Re: Memory leak in bash 4.3
> My hope was that the updated patch I'm about to send would be released
> as bash43-040 in bash-4.3-patches/. Does that make sense, or am I
> missing something obvious?
Here's a corrected patch, and eventually this will be released as an
official patch.
Chet
*** ../bash-4.3-patched/subst.c 2014-10-01 12:57:47.0 -0400
--- subst.c 2015-06-22 09:16:53.0 -0400
***
*** 5783,5787
if (pflags & PF_ASSIGNRHS)
{
! temp = array_variable_name (name, &tt, (int *)0);
if (ALL_ELEMENT_SUB (tt[0]) && tt[1] == ']')
temp = array_value (name, quoted|Q_DOUBLE_QUOTES, 0, &atype, &ind);
--- 5783,5787
if (pflags & PF_ASSIGNRHS)
{
! var = array_variable_part (name, &tt, (int *)0);
if (ALL_ELEMENT_SUB (tt[0]) && tt[1] == ']')
temp = array_value (name, quoted|Q_DOUBLE_QUOTES, 0, &atype, &ind);
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Memory leak in bash 4.3
Hi Chet,
On Mon, 22 Jun 2015 09:40:36 -0400, Chet Ramey wrote:
> > My hope was that the updated patch I'm about to send would be released
> > as bash43-040 in bash-4.3-patches/. Does that make sense, or am I
> > missing something obvious?
>
> Here's a corrected patch, and eventually this will be released as an
> official patch.
>
> Chet
>
> *** ../bash-4.3-patched/subst.c 2014-10-01 12:57:47.0 -0400
> --- subst.c 2015-06-22 09:16:53.0 -0400
> ***
> *** 5783,5787
> if (pflags & PF_ASSIGNRHS)
> {
> ! temp = array_variable_name (name, &tt, (int *)0);
> if (ALL_ELEMENT_SUB (tt[0]) && tt[1] == ']')
> temp = array_value (name, quoted|Q_DOUBLE_QUOTES, 0, &atype, &ind);
> --- 5783,5787
> if (pflags & PF_ASSIGNRHS)
> {
> ! var = array_variable_part (name, &tt, (int *)0);
> if (ALL_ELEMENT_SUB (tt[0]) && tt[1] == ']')
> temp = array_value (name, quoted|Q_DOUBLE_QUOTES, 0, &atype, &ind);
>
Looks good, thank you!
--
Jean Delvare
SUSE L3 Support
?:
In lib/readline/input.c line 108 return (_isatty (fd) ? long) (HANDLE) _get_osfhandle (fd)) & 3) == 3) ? 0); I think you mean return x ? y : z; Unfortunately I don't have a windows machine to test it... --- xoxo iza
Re: ?:
isabella parakiss writes: > In lib/readline/input.c line 108 > return (_isatty (fd) ? long) (HANDLE) _get_osfhandle (fd)) & 3) > == 3) ? 0); Where did you find that? It doesn't occur in the official source. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: ?:
On 6/22/15 10:42 AM, Andreas Schwab wrote: > isabella parakiss writes: > >> In lib/readline/input.c line 108 >> return (_isatty (fd) ? long) (HANDLE) _get_osfhandle (fd)) & 3) >> == 3) ? 0); > > Where did you find that? It doesn't occur in the official source. It's in the devel branch, part of a set of MinGW patches that Eli sent in early January. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ?:
On 6/22/15 10:36 AM, isabella parakiss wrote: > In lib/readline/input.c line 108 > return (_isatty (fd) ? long) (HANDLE) _get_osfhandle (fd)) & 3) > == 3) ? 0); > I think you mean return x ? y : z; Yep, you're right. This is MinGW-specific code. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
