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../.. -I../../lib -I. tparam.c tparam.c: In function 'memory_out': tparam.c:67:3: error: implicit declaration of function 'write' [-Wimplicit-function-declaration] 67 | write (2, "virtual memory exhausted\n", 25); | ^ make[1]: *** [Makefile:56: tparam.o] Error 1 make[1]: Leaving directory '/home/lbl/work/build/bash-5.2.26/lib/termcap' make: *** [Makefile:702: lib/termcap/libtermcap.a] Error 1 --- If I add "#include " to tparam.c, it builds fine. Thanks for the report. I'm more interested in why configuring for your cross-compilation environment doesn't find any of the curses libraries or headers. Do you have them installed? What does config.log say about searching for the curses and termcap libraries? The ancient termcap library bash includes is the bare minimum to get a successful link. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
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 side effects, even in pretty-print mode, so we'll try it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
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 COMMAND is > leaked. Thanks for the report. These are interactive errors only, since a syntax error in a compound command causes the shell to exit. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
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 string int array}
init_vars
This prints the expected output (IMO):
declare -r string="foo"declare -ir int="100"declare -ar array=([0]="1" [1]="2")
Now if I attempt to do the same for local variables declared as such:
foo () { local string local -i int local -a array
init_vars}
foo
This prints different output for the indexed array only:
declare -r string="foo"declare -ir int="100"declare -ar array
Things get even more confusing if I declare an associative array, which
readonly seems to think is now an indexed array, but maybe that's a different
issue.
Thoughts?
TIA,
Will
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 local builtins
do.[1][2] That it might try to anyway is likely unintended.
Your best bet is to do:
array=(1 2)
readonly array
instead of trying to combine the two. This should give you the
behavior you expect.
[1]:
https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html#index-readonly
[2]: https://www.gnu.org/software/bash/manual/html_node/Arrays.html
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.
Also, apologies for the original formatting. It was my first post. Here it is
re-formatted in plain text for posterity:
#
declare string
declare -i int
declare -a array
init_vars () {
readonly string="foo"
readonly int=100
readonly array=(1 2)
# Print the (hopefully) readonly variables
declare -p string int array
}
init_vars
#
This prints the expected output (IMO):
#
declare -r string="foo"
declare -ir int="100"
declare -ar array=([0]="1" [1]="2")
#
Now if I attempt to do the same for local variables declared as such:
#
foo () {
local string
local -i int
local -a array
init_vars
}
foo
#
This prints different output for the indexed array only:
#
declare -r string="foo"
declare -ir int="100"
declare -ar array
#
-Will
On Monday, June 3, 2024 at 03:57:23 PM PDT, Zachary Santer
wrote:
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 local builtins
do.[1][2] That it might try to anyway is likely unintended.
Your best bet is to do:
array=(1 2)
readonly array
instead of trying to combine the two. This should give you the
behavior you expect.
[1]:
https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html#index-readonly
[2]:
https://www.gnu.org/software/bash/manual/html_node/Arrays.html
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. > > > > If a conditional command has a syntax error, the allocated COMMAND is > leaked. > > Thanks for the report. These are interactive errors only, since a syntax > error in a compound command causes the shell to exit. And also syntax errors in `eval' and `.' input when not in POSIX mode. But I agree this kind of fix may not be terribly useful. My goal was to try to get LeakSanitizer results down to a more manageable level, so as to surface interesting leaks more easily, though I'm not sure how far I can really get. I can certainly see the argument for not adding code (and associated runtime overhead for the non-error path) that deals only with avoiding leaks in cases like these. LMK if you don't think changes like this are worthwhile.
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, FUNCTION_DEF
> *value, int flags)
>if (entry && (flags & 1))
> {
>dispose_function_def_contents (entry);
> +
> + cmd = value->command;
> + value->command = 0;
>entry = copy_function_def_contents (value, entry);
> + value->command = cmd;
> }
>else if (entry)
> return;
> --
> 2.45.0
>
Hello,
I haven't looked at this but it will keep lazy functions safe to
implement right?
Lazy functions are functions that redefine themselves the first time
they are called. For example they can call a script containing the
proper implementation with heavier code. Or simplify themselves
depending on the environment or the available tools they detect at
first run.
--
konsolebox
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 to be put in the former hash table, and the metadata (the source-file location and the line where it is defined) are supposed to be put in the latter hash table. However, we reuse the data structure for the function declaration (containing both bodies and metadata) to keep the metadata, and the function bodies were also contained in the latter hash table unintentionally. We've been saving the data that has never been used. -- Koichi
