Re: Bash printf should diagnose integer overflow
On 3/13/24 11:13, Chet Ramey wrote:
Thanks for the report. The most appropriate fix for this particular issue
is to display an error message if printf returns < 0, instead of
suppressing it unless the -v option has been set.
Oh, good point. This simplifies things a bit, though Bash still needs to
do its own overflow checking for cases like "printf '%2147483648q' ''"
and "printf '%*s' 2147483648 ''" when the Bash code itself is parsing
the integer, rather than relying on printf(3) to do it.
Revised patchset attached. The first patch uses the fix you suggested;
the remaining patches are similar to what I sent earlier, except the
last one is simplified since it doesn't need to worry about inline width
and precision when printf will do the checking. These patches are
relative to Bash devel commit bf944fe91ffa97743ad86f6db6f3b84c78207a78
dated today at 09:33:32 -0400.
From 4ca64cfc3de1d9cf75490b85891e88fbf0405538 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 13 Mar 2024 17:00:17 -0700
Subject: [PATCH 1/5] printf now diagnoses underlying printf failure
* builtins/printf.def (printf_builtin):
Report an error if printf returns -1, even when
-v is not used, so that a shell command like
"printf '%1s' ''"
does not fail silently.
---
builtins/printf.def | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtins/printf.def b/builtins/printf.def
index 49757f5c..b1140dc4 100644
--- a/builtins/printf.def
+++ b/builtins/printf.def
@@ -178,8 +178,7 @@ extern int errno;
if (nw < 0 || (vflag == 0 && ferror (stdout))) \
{ \
QUIT; \
- if (vflag) \
- builtin_error ("%s", strerror (errno)); \
+ builtin_error ("%s", strerror (errno)); \
PRETURN (EXECUTION_FAILURE); \
} \
tw += nw; \
--
2.44.0
From 21a3752666536f390f9d5d8378171a4323745adc Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 8 Mar 2024 21:58:46 -0800
Subject: [PATCH 2/5] maint: add support for C23-style stdckdint.h
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is so that Bash can do proper checking for internal
integer overflow. This change doesn't change Bash proper;
it only adds the minimum changes needed so that
C23-style "#include " will work portably
to older systems.
* Makefile.in (CREATED_CONFIGURE): Add stdckdint.h.
* configure.ac: Check for stdckdint.h. If it works, remove
any stdckdint.h left over from a previous ‘configure’;
otherwise, create one.
* .gitignore: Add stdckdint.h.
* include/stdckdint.in.h, include/intprops-internal.h:
New files, copied verbatim from Gnulib.
---
.gitignore | 1 +
Makefile.in | 1 +
configure.ac| 7 +
include/intprops-internal.h | 397
include/stdckdint.in.h | 35
5 files changed, 441 insertions(+)
create mode 100644 include/intprops-internal.h
create mode 100644 include/stdckdint.in.h
diff --git a/.gitignore b/.gitignore
index 2c10177c..15b219d3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -70,6 +70,7 @@ support/bashbug.sh
lsignames.h
pathnames.h
signames.h
+stdckdint.h
version.h
syntax.c
stamp-h
diff --git a/Makefile.in b/Makefile.in
index 41443c6d..2b4b713c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -584,6 +584,7 @@ CREATED_SUPPORT = signames.h recho$(EXEEXT) zecho$(EXEEXT) printenv$(EXEEXT) \
mksyntax${EXEEXT} syntax.c $(VERSPROG) $(VERSOBJ) \
buildversion.o mksignames.o signames.o buildsignames.o
CREATED_CONFIGURE = config.h config.cache config.status config.log \
+ stdckdint.h \
stamp-h po/POTFILES config.status.lineno
CREATED_MAKEFILES = Makefile builtins/Makefile doc/Makefile \
lib/readline/Makefile lib/glob/Makefile \
diff --git a/configure.ac b/configure.ac
index d4ca74e5..7befb6c2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -787,6 +787,7 @@ BASH_HEADER_INTTYPES
AC_CHECK_HEADERS(unistd.h stdlib.h varargs.h limits.h string.h \
memory.h locale.h termcap.h termio.h termios.h dlfcn.h \
+ stdckdint.h \
stdbool.h stddef.h stdint.h netdb.h pwd.h grp.h strings.h \
regex.h syslog.h ulimit.h)
AC_CHECK_HEADERS(sys/pte.h sys/stream.h sys/select.h sys/file.h sys/ioctl.h \
@@ -1352,4 +1353,10 @@ AC_CONFIG_FILES([Makefile builtins/Makefile lib/readline/Makefile \
dnl Makefile uses this timestamp file to record whether config.h is up to date.
AC_CONFIG_COMMANDS([stamp-h], [echo timestamp > stamp-h])
+if test "$ac_cv_header_stdckdint_h" = yes; then
+ rm -f stdckdint.h
+else
+ echo '#include ' >stdckdint.h
+fi
+
AC_OUTPUT
diff --git a/include/intprops-internal.h b/include/intprops-internal.h
new file mode 100644
index ..c8a87d2b
--- /dev/null
+++ b/include/intprops-internal.h
@@ -0,0 +1,397 @@
+/* intprops-internal.h -- properties of integer types not visible to users
+
+ Copyright (C) 2001-2024 Free Software Foundation, Inc.
+
+ This program is free software: you can redistribute it and/or
Re: nameref and referenced variable scope, setting other attributes (was "local -g" declaration references local var in enclosing scope)
On 3/10/24 7:29 PM, Zachary Santer wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: On Sun, Mar 10, 2024 at 3:55 PM Zachary Santer wrote: Relatedly, how would one set attributes on a variable declared in a calling function? 'readonly' and 'export' can do it for their respective attributes, but otherwise, I think you just can't. Second-guessed myself. The manual says about 'declare -n': -n Give each name the nameref attribute, making it a name reference to another variable. That other variable is defined by the value of name. All references, assignments, and attribute modifications to name, except those using or changing the -n attribute itself, are performed on the variable referenced by name's value. The nameref attribute cannot be applied to array variables. local, when called on a nameref variable referencing a variable declared in a calling function, creates a new local variable named the same as the value of the nameref variable. Given the above, I would expect it to instead allow the setting of attributes and value of a variable declared in a calling function. `local' always creates variables at the current scope, or at the global scope if `-g' is supplied. If it's supplied the name of a nameref, it first resolves the nameref to find the name of the variable it's supposed to act on, failing if it can't. Once it has the name it needs, it creates or modifies the variable at the current scope. It doesn't try to create or modify the variable at the nameref's scope. This is one consequence of dynamic scoping that affects the implementation: a nameref's value is just a name, not a pointer to a specific instance of a variable. Once you have that name, the normal scoping rules apply. If you want to look at it from a filesystem perspective, a nameref is a symlink, rather than a hard 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/
Re: Bash printf should diagnose integer overflow
On 3/12/24 3:49 PM, Paul Eggert wrote: Bash Version: 5.3 Patch Level: 26 Release Status: devel Description: Commands like "printf '%1s' ''" silently ignore width and precision. They should report the integer overflow before continuing with a lesser width or precision. Thanks for the report. The most appropriate fix for this particular issue is to display an error message if printf returns < 0, instead of suppressing it unless the -v option has been set. I'll look at the rest of your changes. 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/
Re: multi-threaded compiling
I found another mistake of mine:
#ifndef __STRINGIZED__
should be
#if __STRINGIZED__ == 0
or it will always go for the second statement in the conditional.
Can someone please correct my script??? Things are starting to itch.
On Wed, Mar 13, 2024 at 8:44 AM alex xmb sw ratchev
wrote:
>
>
> On Wed, Mar 13, 2024, 08:26 Mischa Baars
> wrote:
>
>> On Tue, Mar 12, 2024 at 10:00 PM Paul Smith wrote:
>>
>> > On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote:
>> > > > I'd still like to hear why you aren't simply using "make -j".
>> > >
>> > > That's because I don't want to define static compile and link targets
>> > > for every new project I start. The Makefile in question contains only
>> > > a few lines of code and some environment variables, but works on
>> > > every new project as long as you follow certain guidelines regarding
>> > > the directory structure. It scans, compiles and links on the fly.
>> >
>> > I don't find this argument compelling. It's relatively straightforward
>> > to create a makefile environment that "works on every new project as
>> > long as you follow certain guidelines regarding the directory
>> > structure" while still using parallel builds, that will "scan, compile,
>> > and link" on the fly, using things like the wildcard function, pattern
>> > rules, etc.
>> >
>> > You are merely trading a bit of extra complexity in your makefile for a
>> > whole lot of complexity and tricky hacking in bash, as can be seen by
>> > following this thread.
>> >
>>
>> Only the Makefile is functional right now. The bash script is not working.
>> Good enough to reduce compile time from 1:43 to 0:10. I would have liked
>> to
>> see the script working.
>>
>
> u said u have fs naming conventions
> write em up here , i make the bash ( not sh )
>
> But if you prefer to re-invent make's parallel build capabilities in
>> > bash, certainly that's your prerogative.
>> >
>>
>
Makefile
Description: Binary data
/* * * *
* :set tabstop=9
*/
#include
#define str(x) lit(x)
#define lit(x) #x
int main ()
{
#ifndef __STRINGIZED__
const char* s = __STRING__ ;
#else
const char* s = str(__STRING__);
#endif
printf ("STRINGIZED: %d, STRING: %s\n", __STRINGIZED__, s);
}
Re: multi-threaded compiling
On Wed, Mar 13, 2024, 08:26 Mischa Baars wrote: > On Tue, Mar 12, 2024 at 10:00 PM Paul Smith wrote: > > > On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote: > > > > I'd still like to hear why you aren't simply using "make -j". > > > > > > That's because I don't want to define static compile and link targets > > > for every new project I start. The Makefile in question contains only > > > a few lines of code and some environment variables, but works on > > > every new project as long as you follow certain guidelines regarding > > > the directory structure. It scans, compiles and links on the fly. > > > > I don't find this argument compelling. It's relatively straightforward > > to create a makefile environment that "works on every new project as > > long as you follow certain guidelines regarding the directory > > structure" while still using parallel builds, that will "scan, compile, > > and link" on the fly, using things like the wildcard function, pattern > > rules, etc. > > > > You are merely trading a bit of extra complexity in your makefile for a > > whole lot of complexity and tricky hacking in bash, as can be seen by > > following this thread. > > > > Only the Makefile is functional right now. The bash script is not working. > Good enough to reduce compile time from 1:43 to 0:10. I would have liked to > see the script working. > u said u have fs naming conventions write em up here , i make the bash ( not sh ) But if you prefer to re-invent make's parallel build capabilities in > > bash, certainly that's your prerogative. > > >
Re: multi-threaded compiling
On Wed, Mar 13, 2024 at 4:14 AM Martin D Kealey wrote: > > On Mon, Mar 11, 2024 at 8:20 PM Chet Ramey wrote: >> > On 3/11/24 2:50 PM, Mischa Baars wrote: >> > > Which sort of brings us back to the original question I suppose. Who >> does >> > > that line of code function from a script and why does it fail from the >> > > command line? >> > >> > Job control and when the shell notifies the user about job completion, >> > most likely, two of the relevant things that differ between interactive >> > and non-interactive shells. >> > > In this case, no. > > I inserted « echo $- ; shopt -p ; shopt -po ; » in front of each case, and > the ONLY difference was that « echo $- » reported “hxBc” vs “hxB”. Not an > “m” in sight. And no “i” or “l” either. (The “c” was expected, given how « > make » invokes the shell.) > > -Martin >
Re: multi-threaded compiling
On Tue, Mar 12, 2024 at 10:00 PM Paul Smith wrote: > On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote: > > > I'd still like to hear why you aren't simply using "make -j". > > > > That's because I don't want to define static compile and link targets > > for every new project I start. The Makefile in question contains only > > a few lines of code and some environment variables, but works on > > every new project as long as you follow certain guidelines regarding > > the directory structure. It scans, compiles and links on the fly. > > I don't find this argument compelling. It's relatively straightforward > to create a makefile environment that "works on every new project as > long as you follow certain guidelines regarding the directory > structure" while still using parallel builds, that will "scan, compile, > and link" on the fly, using things like the wildcard function, pattern > rules, etc. > > You are merely trading a bit of extra complexity in your makefile for a > whole lot of complexity and tricky hacking in bash, as can be seen by > following this thread. > Only the Makefile is functional right now. The bash script is not working. Good enough to reduce compile time from 1:43 to 0:10. I would have liked to see the script working. But if you prefer to re-invent make's parallel build capabilities in > bash, certainly that's your prerogative. >
