On 8/11/16 5:10 PM, Piotr Grzybowski wrote:
> I personally believe that we should make this change (of course not before
> 4.4 ;-)), and that it should follow the global nameref chain.
> The patch (not breaking the test suite) follows.
The problem with this fix, and part of what makes the
Hi,
amending the previous approach; please find the attached patch: the global
namerefs are followed, and resolved in the function scope. It works as follows:
bash-4.4$ typeset -n v=w; typeset -n w=x; typeset -n x=v; x=4
bash: warning: x: circular name reference.
bash-4.4$ declare -n
Hi,
since we already allow circular refs in the variable_context, the below
answers your request. It means: in the function scope the name references to
existing global variables will be correctly resolved. Please note that using
find_global_variable in
On 8/11/16 12:12 PM, Mike Frysinger wrote:
> On 11 Aug 2016 11:45, Chet Ramey wrote:
>> On 8/11/16 8:30 AM, Mike Frysinger wrote:
>>> These variables are located on the stack and are never read/written
>>> directly by bash. Instead, they're all accessed indirectly via the
>>> POSIX signal API.
On 11 Aug 2016 11:45, Chet Ramey wrote:
> On 8/11/16 8:30 AM, Mike Frysinger wrote:
> > These variables are located on the stack and are never read/written
> > directly by bash. Instead, they're all accessed indirectly via the
> > POSIX signal API. Since POSIX does not require volatile, and bash
On 8/11/16 8:30 AM, Mike Frysinger wrote:
> These variables are located on the stack and are never read/written
> directly by bash. Instead, they're all accessed indirectly via the
> POSIX signal API. Since POSIX does not require volatile, and bash
> itself doesn't require volatile, drop the
On 11 Aug 2016 08:32, Chet Ramey wrote:
> On 8/11/16 8:29 AM, Mike Frysinger wrote:
> > simple code to reproduce:
> > bash -c 'v=$*'
>
> http://lists.gnu.org/archive/html/bug-bash/2016-07/msg00066.html
thanks ... still catching up after vacation and hadn't made it that far yet ;)
-mike
On 8/11/16 8:29 AM, Mike Frysinger wrote:
> simple code to reproduce:
> bash -c 'v=$*'
http://lists.gnu.org/archive/html/bug-bash/2016-07/msg00066.html
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey,
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
externs.h| 2 +-
lib/glob/glob.c | 2 +-
lib/sh/eaccess.c | 10 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git
On systems where sizeof(void*) != sizeof(unsigned int) (e.g. on most
64-bit platforms), we get a warning like so:
tmpfile.c: In function 'sh_seedrand':
tmpfile.c:128:61: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
srandom (tv.tv_sec ^ tv.tv_usec ^
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
general.c | 26 +-
general.h | 18 +-
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/general.c
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
arrayfunc.c | 18 ++
arrayfunc.h | 12 ++--
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arrayfunc.c
These variables are located on the stack and are never read/written
directly by bash. Instead, they're all accessed indirectly via the
POSIX signal API. Since POSIX does not require volatile, and bash
itself doesn't require volatile, drop the volatile markings. If we
don't, you get a lot of
simple code to reproduce:
bash -c 'v=$*'
gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
quote_string (string=0x0) at subst.c:3940
3940 if (*string == 0)
#0 quote_string (string=0x0) at subst.c:3940
#1 0x0045c052 in param_expand
On 8/11/16 5:52 AM, Mike Frysinger wrote:
> ---
> lib/readline/histexpand.c | 1 +
> 1 file changed, 1 insertion(+)
Thanks for the fix.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU
On 8/10/16 5:38 PM, Dmitry Goncharov wrote:
>> > does "If any file argument to one of the primaries is of the form
>
>> > /dev/fd/n, then file descriptor n is checked.".
>
>
>> It seems like a documentation error.
>
> What should the man page say instead?
Probably something close to what the
On 8/11/16 4:54 AM, Mike Frysinger wrote:
> On 12 Jul 2016 21:38, Chet Ramey wrote:
>> +== CHANGES ==+
>> This document details the changes between this version, bash-4.4-beta2, and
>> the previous version, bash-4.4-rc1.
>
> why back to beta ? generally "rc" is considered newer
1. My target was x86-64, using the master 4.3.30 version of bash
(Sorry for lacking the information)
2. I used the master version of bash on the unicode3.sub before
I will test it for the devel version of bash as soon as.
//dengke
On 2016年08月10日 19:10, Chet Ramey wrote:
On 8/10/16
On 12 Jul 2016 21:38, Chet Ramey wrote:
> +== CHANGES ==+
> This document details the changes between this version, bash-4.4-beta2, and
> the previous version, bash-4.4-rc1.
why back to beta ? generally "rc" is considered newer than "beta",
and the previous bash-4.4 releases were
19 matches
Mail list logo
