Chet Ramey writes:
> On 3/24/23 1:23 AM, Sam James wrote:
>
>> I hope so. I'm waiting for a review of an issue in one of its configure
>> checks with a strict compiler too [0].
>> [0]
>> https://lists.gnu.org/archive/html/bug-bash/2023-02/msg0.html
>
> Sorry, I missed that one.
No worries
Not worried, it is legitimately a problem for us to the point we are
currently patching bash to use the monotonic clock for seconds. It times
out stuff in our boot process which executes normally after the time sync
has completed and jumped the clock forward. Rght now, we are just patching
bash
* lib/sh/tmpfile.c (sh_mktmpdir) [!USE_MKDTEMP]:
Fix use of undeclared var 'fd'.
---
lib/sh/tmpfile.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/sh/tmpfile.c b/lib/sh/tmpfile.c
index 18582b10..610bd3dc 100644
--- a/lib/sh/tmpfile.c
+++ b/lib/sh/tmpfile.c
@@
Without this patch, Bash can hand out user-visible timestamps
that are out of order, because on GNU/Linux the 'time'
function uses a different clock than file timestamps
and the 'gettimeofday' function.
The out-of-order timestamps can lead to user-confusion.
* examples/loadables/stat.c (stattime):
* examples/loadables/strftime.c (strftime_builtin):
* lib/readline/examples/histexamp.c (main):
* parse.y (decode_prompt_string):
* support/man2html.c (print_sig):
Do something reasonable if localtime returns NULL.
This can happen, for example, if someone
On 3/23/23 8:24 PM, Paul Eggert wrote:
Without this patch, Bash can hand out user-visible timestamps
that are out of order, because on GNU/Linux the 'time'
function uses a different clock than file timestamps
and the 'gettimeofday' function. See
On 3/23/23 9:49 PM, Paul Eggert wrote:
However, Bash's devel branch still has old-style function definitions and
therefore won't compile with a strict C23 compiler. For example,
get_variable_value in variables.c is old-style. I assume there would be
interest in fixing remaining areas where
On 3/24/23 1:36 AM, Oğuz İsmail Uysal wrote:
On 3/24/23 4:49 AM, Paul Eggert wrote:
a strict C23 compiler
Does such a compiler exist? Is C23 even published yet?
It's not, but the latest drafts are pretty much final, especially with
respect to new features and behavior changes.
--
``The lyf
On 3/23/23 8:42 PM, William Kennington via Bug reports for the GNU Bourne
Again SHell wrote:
We have systems that start off with inaccurate clocks and at some point
after the boot process synchronize with the network and jump forward in
time. This has the potential to break any scripts that are
On 3/19/23 9:12 PM, Grisha Levit wrote:
When HISTTIMEFORMAT is set and history file truncation is performed,
the first line of the history file (i.e. the timestamp of the first
entry) seems to always be missing
Thanks for the report.
Chet
--
``The lyf so short, the craft so long to lerne.''
On 3/24/23 1:23 AM, Sam James wrote:
I hope so. I'm waiting for a review of an issue in one of its configure
checks with a strict compiler too [0].
[0] https://lists.gnu.org/archive/html/bug-bash/2023-02/msg0.html
Sorry, I missed that one.
--
``The lyf so short, the craft so long to
Paul Eggert writes:
> On 3/23/23 18:23, Lawrence Velázquez wrote:
>> On Thu, Mar 23, 2023, at 9:16 PM, Paul Eggert wrote:
>>> I see that Bash won't compile with a C23 compiler, since it still uses
>>> old-style function definitions which C23 no longer supports. Is there
>>> any effort and/or
On 3/24/23 4:49 AM, Paul Eggert wrote:
a strict C23 compiler
Does such a compiler exist? Is C23 even published yet?
13 matches
Mail list logo
