[PATCH] Fix minor portability issues including ISO C 23 prototypes.

Hi, I noticed some compiler warnings that might be worth fixing. I wasn't sure if patches should have ChangeLog entries so I left it alone and tried to make it easy to copy paste for you. Feel free to use or ignore changes as you see fit. Thanks, Collin * lib/malloc/malloc.c (botch): Add correct

Re: [PATCH] Fix minor portability issues including ISO C 23 prototypes.

On 2/14/24 11:56 AM, Chet Ramey wrote: > This isn't necessary in general; ISO C guarantees that a constant > expression with value 0 is a null pointer constant just like NULL, > and the compiler will make them equivalent even if the internal > representation of a null pointer isn't all zeroes. Oop

Re: build failure without system extension macros

Hi Chet, On 5/16/24 7:25 AM, Chet Ramey wrote: > Yes. This was inspired by > > https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00158.html I'm not sure if you have dealt with this particular one yet, but I would just get rid of the u_char, u_short, u_long, types. They are old BSD stuff tha

Incorrect string length check

Hi Chet, In this commit in the devel branch: commit 03c8c43b79177fa678714893e9f05b1c517592c0 Author: Chet Ramey Date: Fri Apr 5 09:03:52 2024 -0400 man page typesetting updates for compatibilityand layout issues I think there was a typo in execute_cmd.c: diff --git a/execute_cmd.c b/exe

Re: printf %m$ and %*m$ unimplemented in Bash, but implementated in C compilers

porterleete writes: > Fix: > Either update the documentation of what printf in bash actually does. > If printf is using a standard for printf other than "what the biggest > C compilers currently do", document which standard it's using or > update it to the newest standard used by gcc and clang.

[PATCH] malloc: fix out-of-bounds read

an atleast. I didn't look into the surrounding code much so a double check would be nice. :) Collin >From 4863afd5260e11f05f69adc64c496f6d8bace627 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Thu, 18 Jul 2024 21:45:51 -0700 Subject: [PATCH] malloc: fix out-of-bounds read * lib/ma

Re: [PATCH] malloc: fix out-of-bounds read

Hi Chet, Chet Ramey writes: >> /* Use this when we want to be sure that NB is in bucket NU. */ >> #define RIGHT_BUCKET(nb, nu) \ >> (((nb) > binsizes[(nu)-1]) && ((nb) <= binsizes[(nu)])) > > The right fix here is two-fold: fix the first test here to evaluate to 0 > if nu == 0, and change t

Out of bounds read in parse.y.

Hi, When compiling with undefined behavior sanitizer and then running: $ ./bash parse.y:1000:93: runtime error: index -1 out of bounds for type 'int [257]' The offending section of code: case_command: CASE WORD newline_list IN newline_list ESAC {

Re: Out of bounds read in parse.y.

Hi Chet, Chet Ramey writes: > Which version? This was from bash devel branch, commit hash 2e01122fe78eb5a42c9b9f3ca46b91f895959675. Built with: ./configure CFLAGS='-fsanitize=undefined' > Why? 0 is a valid index. set_word_top increments word_top before assigning > to word_lineno[word_top

Re: Out of bounds read in parse.y.

Chet Ramey writes: > Thanks. Here's the simple reproducer: > > x() > { > case y in > z) > if (! false); then > foo=bar > fi > ;; > esac > } > > > It was what I suspected. Ah, nice! Thank you for the help. Collin

Re: Is this a bug?

Hi, George R Goffe writes: > I've been trying to build bash from a repository > "https://git.savannah.gnu.org/git/bash.git"; and a having the devil's own time > in the process. > > Did I just catch the repository in the middle of a rework? I have a > full log of the build process if it's neede