Re: [bug #65827] Cross-compilation fails with gcc 14.1.0

On 6/2/24 9:43 AM, Brett Neumeier wrote: ./configure --build=x86_64-unknown-linux-gnu --host=aarch64-cbl-linux-gnu --enable-static-link --without-bash-malloc I get this failure: --- aarch64-cbl-linux-gnu-gcc -c -I/home/lbl/work/sysroot/scaffolding/include -DHAVE_CONFIG_H -I. -I../.. -I../

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

On 6/1/24 7:15 AM, Koichi Murase wrote: This patch fixes `bind_function_def' so that it skips the function body also for the second and later calls. This reduces the memory uses of Bash for shell functions by almost half. Thanks for the analysis and patch. This should not have any negative si

Re: [PATCH] coproc: do not leak name

On 5/31/24 5:32 PM, Grisha Levit wrote: When a named coproc is created, the name string and associated WORD_DESC are leaked. Thanks for the report. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech,

Re: [PATCH] expand_word_internal: fix leak with W_NOSPLIT2

On 5/31/24 6:55 PM, Grisha Levit wrote: Free temporary list allocated when exapnding `$@' in bash -c 'IFS=:; : ${_+$@}' _ X Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, C

Re: [PATCH] cond expr: cleanup on errors

On 5/31/24 5:07 PM, Grisha Levit wrote: Two minor leak fixes for conditional command error conditions: If a WORD token is read when COND_AND, COND_OR, COND_END, or a binary operator are expected, the allocated WORD_DESC is leaked. If a conditional command has a syntax error, the allocated COMMA

readonly inconsistency with arrays

I'm seeing what appears to be an inconsistency with using `readonly` on variables declared in a previous scope. declare stringdeclare -i intdeclare -a array init_vars () {  readonly string="foo"  readonly int=100  readonly array=(1 2)   # Print the (hopefully) readonly variables  declare -p strin

Re: readonly inconsistency with arrays

On Mon, Jun 3, 2024 at 6:16 PM Will Allan via Bug reports for the GNU Bourne Again SHell wrote: > > init_vars () { readonly string="foo" readonly int=100 readonly array=(1 2) My understanding is that the readonly builtin isn't supposed to handle compound assignment syntax like the declare and

Re: readonly inconsistency with arrays

Thanks for the workaround. It's odd that it appears to work for scalar types in both cases, but not indexed arrays (in the second case) or associative arrays (in both cases). Would be nice to save an extra line when initializing and freezing each variable like you can do with declare/local. Als

Re: [PATCH] cond expr: cleanup on errors

On Mon, Jun 3, 2024 at 3:53 PM Chet Ramey wrote: > > On 5/31/24 5:07 PM, Grisha Levit wrote: > > Two minor leak fixes for conditional command error conditions: > > > > If a WORD token is read when COND_AND, COND_OR, COND_END, or a binary > > operator are expected, the allocated WORD_DESC is leaked

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

On Sat, Jun 1, 2024 at 7:16 PM Koichi Murase wrote: > > --- > variables.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/variables.c b/variables.c > index 84b30d93..0e785742 100644 > --- a/variables.c > +++ b/variables.c > @@ -3507,7 +3507,11 @@ bind_function_def (const char *name,

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

2024年6月4日(火) 15:11 konsolebox : > I haven't looked at this but it will keep lazy functions safe to > implement right? Right. The fix shouldn't change the observable behavior. The functions are saved in two hash tables, `shell_functions' and `shell_function_defs'. The function bodies are supposed