Re: Relicense findprog-in under LGPLv2+

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

Re: checking against signed integer overflow

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 requi

Re: checking against signed integer overflow

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 inst

Re: checking against signed integer overflow

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 overf

Relicense findprog-in under LGPLv2+

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

Re: checking against signed integer overflow

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

Re: checking against signed integer overflow

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 Corp

Re: checking against signed integer overflow

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 tha

[PATCH] 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. --- ChangeLog | 5 + doc/gnulib-readme.texi | 10 +- 2 files changed, 10 insertions(+), 5 deletions(-)

Re: checking against signed integer overflow

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 Fed

Re: checking against signed integer overflow

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.

Re: checking against signed integer overflow

> > > 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

Re: checking against signed integer overflow

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 >

Re: C++ and read redefinition

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 functio

Re: checking against signed integer overflow

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.

Re: Make more use of idx_t

Paul Eggert wrote: > Those all look good to me. OK, I pushed them. Bruno