Re: Make more use of idx_t

[Bruno Haible]

Paul Eggert wrote:
> Those all look good to me.

OK, I pushed them.

Bruno

Re: checking against signed integer overflow

[Bruno Haible]

Hi Paul,

> I installed the attached patch to do that

Very nice! I made a tweak to the first example, to use printf() instead of
print(). Hope you agree.

> Your reaction to the *_WRAPV names just goes to show how bad I am with 
> marketing

This set of macros would be worth publicizing, e.g. through an announcement
on planet.gnu.org. If you agree, we would
  1) publish the current gnulib doc on www.gnu.org (as we do occasionally
 anyway) [I can do that],
  2) write a news entry in https://savannah.gnu.org/projects/gnulib
  3) approve it, also through https://savannah.gnu.org/projects/gnulib


2020-12-06  Bruno Haible  

doc: Tweak example.
* doc/intprops.texi (Checking Integer Overflow): Use 'printf', not
'print'.

diff --git a/doc/intprops.texi b/doc/intprops.texi
index f3a958a..b668285 100644
--- a/doc/intprops.texi
+++ b/doc/intprops.texi
@@ -167,7 +167,7 @@ arithmetic.  For example:
 if ((a + b < b) == (a < 0))
   a += b;
 else
-  print ("overflow");
+  printf ("overflow\n");
 @end example
 
 @noindent

Re: C++ and read redefinition

[Bruno Haible]

Daniel R. Hurtmans wrote:
> undefined reference to `std::basic_ifstream 
>  >::_close()'

Oh, so the OpenMP #pragma is not the only problem. It potentially affects
all of the symbols that are #defined.

I'm committing the attached two patches. The idea is to not use #defines
for redirecting functions in C++ mode, when GNULIB_NAMESPACE is defined.

With these patches, you should be able to revert the workaround that I
suggested earlier. But you need to define GNULIB_NAMESPACE.


2020-12-06  Bruno Haible  

Do the Windows oldnames workaround through the C++ GNULIB_NAMESPACE.
Reported by Daniel R. Hurtmans  in
.
* lib/c++defs.h (_GL_CXXALIAS_MDA_CAST): New macro.
* lib/fcntl.in.h (creat, open):  In C++ mode, when GNULIB_NAMESPACE is
defined: 1. Define a symbol in this namespace. 2. Don't redirect using
a preprocessor #define.
* lib/math.in.h (j0, j1, jn, y0, y1, yn): Likewise.
* lib/search.in.h (lfind, lsearch): Likewise.
* lib/stdio.in.h (fcloseall, fdopen, fileno, getw, putw, tempnam):
Likewise.
* lib/stdlib.in.h (ecvt, fcvt, gcvt, mktemp, putenv): Likewise.
* lib/string.in.h (memccpy, strdup): Likewise.
* lib/sys_stat.in.h (chmod, umask): Likewise.
* lib/time.in.h (tzset): Likewise.
* lib/unistd.in.h (access, chdir, close, dup, dup2, execl, execle,
execlp, execv, execve, execvp, execvpe, getcwd, getpid, isatty, lseek,
read, rmdir, swab, unlink, write): Likewise.
* lib/utime.in.h (utime): Likewise.
* lib/wchar.in.h (wcsdup): Likewise.
* m4/stdio_h.m4 (gl_STDIO_H_DEFAULTS): Initialize HAVE_DECL_FCLOSEALL.
(gl_STDIO_H): Set HAVE_DECL_FCLOSEALL.
* modules/stdio (Makefile.am): Substitute HAVE_DECL_FCLOSEALL.
* m4/stdlib_h.m4 (gl_STDLIB_H_DEFAULTS): Initialize HAVE_DECL_ECVT,
HAVE_DECL_FCVT, HAVE_DECL_GCVT.
(gl_STDLIB_H): Set HAVE_DECL_ECVT, HAVE_DECL_FCVT, HAVE_DECL_GCVT.
* modules/stdlib (Makefile.am): Substitute HAVE_DECL_ECVT,
HAVE_DECL_FCVT, HAVE_DECL_GCVT.
* m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Initialize HAVE_DECL_EXECVPE.
(gl_UNISTD_H): Set HAVE_DECL_EXECVPE.
* modules/unistd (Makefile.am): Substitute HAVE_DECL_EXECVPE.
* m4/wchar_h.m4 (gl_WCHAR_H_DEFAULTS): Initialize HAVE_DECL_WCSDUP.
(gl_WCHAR_H): Set HAVE_DECL_WCSDUP.
* modules/wchar (Makefile.am): Substitute HAVE_DECL_WCSDUP.

2020-12-06  Bruno Haible  

doc: Mention some missing function declarations.
* doc/glibc-functions/execvpe.texi: Mention the missing declaration on
AIX.
* doc/glibc-functions/fcloseall.texi: Mention the missing declaration on
FreeBSD.
* doc/pastposix-functions/ecvt.texi: Mention the missing declaration on
Cygwin.
* doc/pastposix-functions/fcvt.texi: Likewise.
* doc/pastposix-functions/gcvt.texi: Likewise.

>From 5af457737fb72ec05544a3336ce4b867b744b4d2 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 6 Dec 2020 15:51:41 +0100
Subject: [PATCH 1/2] doc: Mention some missing function declarations.

* doc/glibc-functions/execvpe.texi: Mention the missing declaration on
AIX.
* doc/glibc-functions/fcloseall.texi: Mention the missing declaration on
FreeBSD.
* doc/pastposix-functions/ecvt.texi: Mention the missing declaration on
Cygwin.
* doc/pastposix-functions/fcvt.texi: Likewise.
* doc/pastposix-functions/gcvt.texi: Likewise.
---
 ChangeLog  | 12 
 doc/glibc-functions/execvpe.texi   |  3 +++
 doc/glibc-functions/fcloseall.texi |  3 +++
 doc/pastposix-functions/ecvt.texi  |  3 +++
 doc/pastposix-functions/fcvt.texi  |  3 +++
 doc/pastposix-functions/gcvt.texi  |  3 +++
 6 files changed, 27 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 8f749e2..d7ef879 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,17 @@
 2020-12-06  Bruno Haible  
 
+	doc: Mention some missing function declarations.
+	* doc/glibc-functions/execvpe.texi: Mention the missing declaration on
+	AIX.
+	* doc/glibc-functions/fcloseall.texi: Mention the missing declaration on
+	FreeBSD.
+	* doc/pastposix-functions/ecvt.texi: Mention the missing declaration on
+	Cygwin.
+	* doc/pastposix-functions/fcvt.texi: Likewise.
+	* doc/pastposix-functions/gcvt.texi: Likewise.
+
+2020-12-06  Bruno Haible  
+
 	doc: Tweak example.
 	* doc/intprops.texi (Checking Integer Overflow): Use 'printf', not
 	'print'.
diff --git a/doc/glibc-functions/execvpe.texi b/doc/glibc-functions/execvpe.texi
index 5c11ad6..814b160 100644
--- a/doc/glibc-functions/execvpe.texi
+++ b/doc/glibc-functions/execvpe.texi
@@ -15,4 +15,7 @@ Portability problems not fixed by Gnulib:
 @item
 This function is missing on many non-glibc platforms:
 glibc 2.10, Mac OS X 10.13, FreeBSD 6.0, NetBSD 7.1, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, Sol

Re: checking against signed integer overflow

[Bruno Haible]

Paul Eggert wrote:
> I gave it a shot by installing the attached patches.

Thanks. This could even be moved to the Autoconf manual, if there is
sufficient agreement among GNU developers.

> what Florian said a couple of years ago 
> .

This is worth reading; thanks. Note that the option '-mcet' does not actually
exist. I guess it was folded into the '-fcf-protection=...' option before
GCC 8.1 was released. Cf. 

> I'm reluctant to recommend -fsanitize=whatever flags for production builds 
> because they're ABI-incompatible with future library versions

Florian's post mentions
  "the Address Sanitizer interceptors disable ABI compatibility with future
   library versions."
This in understandable: A pointer into an array may be passed as a 3 words
(array start, array end, and actual pointer value).

But for '-fsanitize=signed-integer-overflow' there is no reason for an
ABI change. It's only the code inside functions which behaves differently.

> > Would it make sense to tell the GCC people that
> >- the '-fsanitize=signed-integer-overflow 
> > -fno-sanitize-recover=signed-integer-overflow'
> >  options are practically useless when they force a dependency towards 
> > libstdc++,

Reported as .

> >- the 'ftrapv' option is useless when it does not work in combination 
> > with
> >  '-O2' ?
> 
> I'm not observing the latter problem with GCC 10.2.1 (Red Hat 10.2.1-9) on 
> Fedora 33 x86-64; maybe it's fixed now?

Oops, indeed. My test program could be optimized in way that the overflow
disappears. Find attached a corrected test program.

So, '-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error' and
'-ftrapv' both work. The former generates better code, whereas the latter has
less surprising behaviour (an abort() is a better response than an illegal
instruction, IMO).

I'll try to use '-ftrapv' globally, to see how this works out.

Bruno
#include 

unsigned int ua = 0xA000;
unsigned int ub = 0x7000;
unsigned int uc;
int a = 0x5000;
int b = 0x6000;
int c;

int main ()
{
  uc = ua + ub;
  c = a + b;
  c += b;
  c += b;
  c += b;
  printf ("Still there.\n");
  return 0;
}

Re: checking against signed integer overflow

[Bruno Haible]

> > > Would it make sense to tell the GCC people that
> > >- the '-fsanitize=signed-integer-overflow 
> > > -fno-sanitize-recover=signed-integer-overflow'
> > >  options are practically useless when they force a dependency towards 
> > > libstdc++,
> 
> Reported as .

The solution to this problem is to use the option '-static-libubsan'.

I'm expanding the documentation a bit:


2020-12-06  Bruno Haible  

doc: Add more details regarding the undefined behaviour sanitizer.
* doc/gnulib-readme.texi (High Quality): Describe
-fsanitize-undefined-trap-on-error better.

diff --git a/doc/gnulib-readme.texi b/doc/gnulib-readme.texi
index a2a5962..cde6d7a 100644
--- a/doc/gnulib-readme.texi
+++ b/doc/gnulib-readme.texi
@@ -546,8 +546,21 @@ for your compiler.  For example:
 @end example
 
 @noindent
-Here, @code{-D_FORTIFY_SOURCE=2} enables extra security hardening
-checks in the GNU C library, @code{-fsanitize=undefined} enables GCC's
-undefined behavior sanitizer (@code{ubsan}), and
-@code{-fsanitize-undefined-trap-on-error} prevents @code{ubsan}'s
-linking to unnecessary libraries like @code{libstdc++}.
+Here:
+
+@itemize @bullet
+@item
+@code{-D_FORTIFY_SOURCE=2} enables extra security hardening checks in
+the GNU C library.
+@item
+@code{-fsanitize=undefined} enables GCC's undefined behavior sanitizer
+(@code{ubsan}), and
+@item
+@code{-fsanitize-undefined-trap-on-error} causes @code{ubsan} to
+abort the program (through an ``illegal instruction'' signal).  This
+measure stops exploit attempts and also allows you to debug the issue.
+Without this option, @code{-fsanitize=undefined} causes messages to be
+printed, execution continues after an undefined behavior situation, and
+GCC links the program against @code{libstdc++} (which you can avoid
+through the option @code{-static-libubsan}).
+@end itemize

Re: checking against signed integer overflow

[Paul Eggert]

On 12/6/20 8:30 AM, Bruno Haible wrote:


Thanks. This could even be moved to the Autoconf manual, if there is
sufficient agreement among GNU developers.


Could be, once we figure out what should be in it. :-) Though this stuff really 
should be documented better in the GCC manual, I suppose.



for '-fsanitize=signed-integer-overflow' there is no reason for an
ABI change. It's only the code inside functions which behaves differently.


The main issue here is which of these options are intended to be used in 
production code. For those options there will be a lot of user pressure for 
backward-compatibility support, due to the dusty-binary problem. For debugging 
options there won't be. -fsanitize=undefined is intended to be for debugging; if 
we start using it in production code there may be a clash down the line (RHEL 
changes some way that the error message gets printed, say).



So, '-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error' and
'-ftrapv' both work. The former generates better code, whereas the latter has
less surprising behaviour (an abort() is a better response than an illegal
instruction, IMO).


Yes, we've discussed this before. I'd rather not have call 'abort' here, since 
arithmetic overflow failures are in the same category as dividing by zero or 
(INT_MIN / -1) and 'abort' isn't called there either.  Calling 'abort' slightly 
complicates the way I debug, and it's just one more thing that can go wrong at 
least in theory (stack space exhaustion, PLT corruption, etc.). Plus it bloats 
the code a bit.


It's not a big deal either way, for typical debugging. For production code, 
though, traps look better to me.

Re: checking against signed integer overflow

[Paul Eggert]

On 12/6/20 9:00 AM, Bruno Haible wrote:


The solution to this problem is to use the option '-static-libubsan'.


Unfortunately -static-libusan doesn't solve the whole problem of dynamically 
linking to extra libraries, and it introduces problems of its own. When I build 
your foo.c program on Fedora 33 x86-64:


$ gcc -O2 foo.c
$ size a.out
   textdata bss dec hex filename
   1231 548  121791 6ff a.out
$ ldd a.out
linux-vdso.so.1 (0x7ffe583c8000)
libc.so.6 => /lib64/libc.so.6 (0x7f60a557f000)
/lib64/ld-linux-x86-64.so.2 (0x7f60a576e000)
$ gcc -fsanitize=undefined -fsanitize-undefined-trap-on-error -O2 foo.c
$ size a.out
   textdata bss dec hex filename
   1247 548  121807 70f a.out
$ ldd a.out
linux-vdso.so.1 (0x7ffe0b10)
libc.so.6 => /lib64/libc.so.6 (0x7f79f2d98000)
/lib64/ld-linux-x86-64.so.2 (0x7f79f2f87000)
$ gcc -fsanitize=undefined -static-libubsan -O2 foo.c
$ size a.out
   textdata bss dec hex filename
 274576   15912  593416  883904   d7cc0 a.out
$ ldd a.out
linux-vdso.so.1 (0x7ffe15d15000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f0bc6af6000)
librt.so.1 => /lib64/librt.so.1 (0x7f0bc6aeb000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f0bc6ac9000)
libm.so.6 => /lib64/libm.so.6 (0x7f0bc6983000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f0bc6968000)
libc.so.6 => /lib64/libc.so.6 (0x7f0bc679d000)
/lib64/ld-linux-x86-64.so.2 (0x7f0bc6b21000)
$ gcc -fsanitize=undefined -O2 foo.c
$ size a.out
   textdata bss dec hex filename
   1511 660  122183 887 a.out
$ ldd a.out
linux-vdso.so.1 (0x7ffc208cd000)
libubsan.so.1 => /lib64/libubsan.so.1 (0x7fac5540e000)
libc.so.6 => /lib64/libc.so.6 (0x7fac55243000)
libdl.so.2 => /lib64/libdl.so.2 (0x7fac5523c000)
librt.so.1 => /lib64/librt.so.1 (0x7fac55231000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7fac5520f000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7fac55027000)
libm.so.6 => /lib64/libm.so.6 (0x7fac54edf000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fac54ec4000)
/lib64/ld-linux-x86-64.so.2 (0x7fac55d9d000)

I tried to condense all this into something short and installed the attached 
into the Gnulib manual.
From d058c47204168676d6fe02b18d51916a1045149e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 6 Dec 2020 10:03:37 -0800
Subject: [PATCH] doc: document -static-libubsan more

* doc/gnulib-readme.texi (High Quality): Document pros and cons of
-static-libubsan a bit more.  Mostly cons.
---
 ChangeLog  |  6 ++
 doc/gnulib-readme.texi | 16 
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 08cef4d15..14a2ea957 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2020-12-06  Paul Eggert  
+
+	doc: document -static-libubsan more
+	* doc/gnulib-readme.texi (High Quality): Document pros and cons of
+	-static-libubsan a bit more.  Mostly cons.
+
 2020-12-06  Bruno Haible  
 
 	doc: Add more details regarding the undefined behaviour sanitizer.
diff --git a/doc/gnulib-readme.texi b/doc/gnulib-readme.texi
index cde6d7aab..833888320 100644
--- a/doc/gnulib-readme.texi
+++ b/doc/gnulib-readme.texi
@@ -559,8 +559,16 @@ the GNU C library.
 @code{-fsanitize-undefined-trap-on-error} causes @code{ubsan} to
 abort the program (through an ``illegal instruction'' signal).  This
 measure stops exploit attempts and also allows you to debug the issue.
-Without this option, @code{-fsanitize=undefined} causes messages to be
-printed, execution continues after an undefined behavior situation, and
-GCC links the program against @code{libstdc++} (which you can avoid
-through the option @code{-static-libubsan}).
 @end itemize
+
+Without the @code{-fsanitize-undefined-trap-on-error} option,
+@code{-fsanitize=undefined} causes messages to be printed, and
+execution continues after an undefined behavior situation.
+The message printing causes GCC-like compilers to arrange for the
+program to dynamically link to libraries it might not otherwise need.
+With GCC, instead of @code{-fsanitize-undefined-trap-on-error} you can
+use the @code{-static-libubsan} option to arrange for two of the extra
+libraries (@code{libstdc++} and @code{libubsan}) to be linked
+statically rather than dynamically, though this typically bloats the
+executable and the remaining extra libraries are still linked
+dynamically.
-- 
2.27.0

[PATCH] doc: fix flat address space discussion

[Paul Eggert]

* doc/gnulib-readme.texi (Other portability assumptions):
Move the all-bits-zero assumption outside the flat address space
section, since the two issues are independent.
---
 ChangeLog  |  5 +
 doc/gnulib-readme.texi | 10 +-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 14a2ea957..5f4ae46a6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2020-12-06  Paul Eggert  
 
+   doc: fix flat address space discussion
+   * doc/gnulib-readme.texi (Other portability assumptions):
+   Move the all-bits-zero assumption outside the flat address space
+   section, since the two issues are independent.
+
doc: document -static-libubsan more
* doc/gnulib-readme.texi (High Quality): Document pros and cons of
-static-libubsan a bit more.  Mostly cons.
diff --git a/doc/gnulib-readme.texi b/doc/gnulib-readme.texi
index 833888320..3854829af 100644
--- a/doc/gnulib-readme.texi
+++ b/doc/gnulib-readme.texi
@@ -465,6 +465,11 @@ contribute to its value in the usual way.
 In particular, an unsigned type and its signed counterpart have the
 same number of bits when you count the latter's sign bit.
 
+@item
+Objects with all bits zero are treated as 0 or NULL@.  For example,
+@code{memset@ (A, 0, sizeof@ A)} initializes an array @code{A} of
+pointers to NULL.
+
 @item
 The types @code{intptr_t} and @code{uintptr_t} exist, and pointers
 can be converted to and from these types without loss of information.
@@ -505,11 +510,6 @@ Overflow in this case would mean that the rest of your 
program fits
 into @var{T} bytes, which can't happen in realistic flat-address-space
 hosts.
 
-@item
-Objects with all bits zero are treated as 0 or NULL@.  For example,
-@code{memset@ (A, 0, sizeof@ A)} initializes an array @code{A} of
-pointers to NULL.
-
 @item
 Adding zero to a null pointer does not change the pointer.
 For example, @code{0 + (char *) NULL == (char *) NULL}.
-- 
2.27.0

Re: checking against signed integer overflow

[Jeffrey Walton]

On Sun, Dec 6, 2020 at 1:06 PM Paul Eggert  wrote:
> ...
> > So, '-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error' 
> > and
> > '-ftrapv' both work. The former generates better code, whereas the latter 
> > has
> > less surprising behaviour (an abort() is a better response than an illegal
> > instruction, IMO).
>
> Yes, we've discussed this before. I'd rather not have call 'abort' here, since
> arithmetic overflow failures are in the same category as dividing by zero or
> (INT_MIN / -1) and 'abort' isn't called there either.  Calling 'abort' 
> slightly
> complicates the way I debug, and it's just one more thing that can go wrong at
> least in theory (stack space exhaustion, PLT corruption, etc.). Plus it bloats
> the code a bit.

+1, never call abort(). A library should not be setting policies for a
program. It is up to the developer to determine his/her policy.

For me reasons why an abort() is bad, see
https://www.cryptopp.com/wiki/Assertions#Library_Position.

Jeff

Re: checking against signed integer overflow

[Paul Eggert]

On 12/5/20 7:36 PM, Bruno Haible wrote:


(*) The function did a Montgomery multiplication mod p, where p > 2^128; this
is the workhorse of the arithmetic on an elliptic curve.
Small world. I worked with the late Peter Montgomery circa 1980; he was down the 
hall from me at System Development Corporation in Santa Monica, and was 
developing what led to Montgomery multiplication, though due to security 
regulations I never really knew what he was up to at the time. He was such a 
nice guy, with a great attitude, and was a pleasure to be around.


Peter was famous for his mastery of the CDC 7600, the fastest computer in the 
world in the early 1970s. If you wanted fast math code, he was *the guy*. And 
the CDC 7600 used 60-bit ones'-complement integer arithmetic, so this email 
isn't *entirely* a digression.

Re: checking against signed integer overflow

[Bruno Haible]

Paul Eggert wrote:
> > for '-fsanitize=signed-integer-overflow' there is no reason for an
> > ABI change. It's only the code inside functions which behaves differently.
> 
> The main issue here is which of these options are intended to be used in 
> production code. For those options there will be a lot of user pressure for 
> backward-compatibility support, due to the dusty-binary problem. For 
> debugging 
> options there won't be. -fsanitize=undefined is intended to be for debugging

Indeed, this is a problem. It would not be good if the GCC people turn down
enhancement improvements for ubsan with the argument that it is not binary
backward compatible.

> > So, '-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error' 
> > and
> > '-ftrapv' both work. The former generates better code, whereas the latter 
> > has
> > less surprising behaviour (an abort() is a better response than an illegal
> > instruction, IMO).
> 
> Yes, we've discussed this before. I'd rather not have call 'abort' here, 
> since 
> arithmetic overflow failures are in the same category as dividing by zero or 
> (INT_MIN / -1) and 'abort' isn't called there either.

Sorry, I had not remembered this earlier discussion. Did we discuss the signal
with which the process should be terminated? Division by zero and (INT_MIN / -1)
raise a SIGFPE signal (at least on some CPUs), and this signal is defined as
"Erroneous arithmetic operation." [1] Like you say, signed integer overflow
should raise the same signal. Then, SIGILL is just as wrong as SIGABRT.

Bruno

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

Relicense findprog-in under LGPLv2+

[Bruno Haible]

Hi Paul,

I would like to relicense the module 'findprog-in' under LGPLv2+, so that
I can use it for the native Windows implementation of the modules 'posix_spawn'
and 'posix_spawnp' — which are under LGPLv2+.

This module has one contribution from you:
https://lists.gnu.org/archive/html/bug-gnulib/2019-09/msg00062.html

Would you approve this license change for this contribution?

(Of course the dependency to the 'xalloc' module will then also go away,
and be replaced with an error return with errno = ENOMEM.)

Bruno

Re: checking against signed integer overflow

[Paul Eggert]

On 12/6/20 12:21 PM, Bruno Haible wrote:

Did we discuss the signal
with which the process should be terminated? Division by zero and (INT_MIN / -1)
raise a SIGFPE signal (at least on some CPUs), and this signal is defined as
"Erroneous arithmetic operation." [1] Like you say, signed integer overflow
should raise the same signal. Then, SIGILL is just as wrong as SIGABRT.


I don't remember whether we discussed which signal should be given.

This issue has been a mess for decades; SIGFPE originally was meant just for 
floating-point exceptions but got hijacked by some integer operations on many 
platforms. At this point it would be better for integer arithmetic overflow to 
generate SIGFPE in some way that a signal handler could tell the difference, but 
this is not a hill I'm prepared to die on and if it requires significantly more 
runtime library code or extra instructions in the executable I wouldn't bother. 
It's enough for me that *some* otherwise-unlikely but fatal signal is generated.

Re: checking against signed integer overflow

[Bruno Haible]

Paul Eggert wrote:
> At this point it would be better for integer arithmetic overflow to 
> generate SIGFPE in some way that a signal handler could tell the difference, 
> but 
> this is not a hill I'm prepared to die on and if it requires significantly 
> more 
> runtime library code or extra instructions in the executable I wouldn't 
> bother.

While glibc already documents that SIGFPE could be signalled for integer
overflow, with code FPE_INTOVF_TRAP [1], I don't know how user-space code
could generate such a signal: raise() doesn't take a second argument,
and sigqueue() sets the code to SI_QUEUE, not FPE_INTOVF_TRAP. [2]

Bruno

[1] 
https://www.gnu.org/software/libc/manual/html_node/Program-Error-Signals.html
[2] https://www.kernel.org/doc/man-pages/online/pages/man2/sigqueue.2.html

Re: checking against signed integer overflow

[Jeffrey Walton]

On Sun, Dec 6, 2020 at 11:19 PM Bruno Haible  wrote:
>
> Paul Eggert wrote:
> > At this point it would be better for integer arithmetic overflow to
> > generate SIGFPE in some way that a signal handler could tell the 
> > difference, but
> > this is not a hill I'm prepared to die on and if it requires significantly 
> > more
> > runtime library code or extra instructions in the executable I wouldn't 
> > bother.
>
> While glibc already documents that SIGFPE could be signalled for integer
> overflow, with code FPE_INTOVF_TRAP [1], I don't know how user-space code
> could generate such a signal: raise() doesn't take a second argument,
> and sigqueue() sets the code to SI_QUEUE, not FPE_INTOVF_TRAP. [2]

Another thing to be careful of is, if there is no signal handler in
place (like for SIGTRAP), then what happens after the signal is raised
depends on the OS. I believe Linux will allow the program to continue
after an uncaught SIGTRAP. Modern OS X will still abort even though
that's the exact behavior you are trying to avoid by not using asserts
with its SIGABRT.

And one more point about asynchronous signals... They disgorge the
point of failure from the handler. I think the best strategy is to use
an API that returns an immediate result. The program then can handle
the failure as it sees fit at the point of failure, and not some
callback with restrictions.

Jeff

Re: Relicense findprog-in under LGPLv2+

[Paul Smith]

On Sun, 2020-12-06 at 22:59 +0100, Bruno Haible wrote:
> I would like to relicense the module 'findprog-in' under LGPLv2+, so
> that I can use it for the native Windows implementation of the
> modules 'posix_spawn' and 'posix_spawnp' — which are under LGPLv2+.
> 
> This module has one contribution from you:
> 
> https://lists.gnu.org/archive/html/bug-gnulib/2019-09/msg00062.html
> 
> Would you approve this license change for this contribution?

Yes, that's fine.

Thanks Bruno.