Re: checking against signed integer overflow

Hi Paul, > >1) publish the current gnulib doc on www.gnu.org (as we do occasionally > > anyway) [I can do that], I just published the doc now. > >2) write a news entry in https://savannah.gnu.org/projects/gnulib > >3) approve it, also through https://savannah.gnu.org/projects/g

Re: checking against signed integer overflow

On 12/6/20 4:05 AM, Bruno Haible wrote: 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

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

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

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: 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: checking against signed integer overflow

Paul Eggert wrote: > The Gnulib intprops module doesn't use asms and does not rely on undefined > behavior, > and I'd be surprised if it's significantly outperformed by the usual asms for > this particular task. Yes. Already in 1999 I made the experience that, for a function that contained lots o

Re: checking against signed integer overflow

On 12/5/20 7:03 AM, Bruno Haible wrote: * The only appropriate answer that is left is '-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error'. Could we document this in the Gnulib documentation? I gave it a shot by installing the attached patches. There are a bunch of

Re: checking against signed integer overflow

On 12/5/20 1:42 PM, Bruno Haible wrote: How about adding a macro #define SAFE_INT_MULTIPLY(a, b, result) \ ! INT_MULTIPLY_WRAPV (a, b, result) and documenting it as a safe way to do integer multiplication, regardless of compiler options in effect? Sure, we can do that. I prefer the na

Re: checking against signed integer overflow

Paul Eggert wrote: > the safe-iop function 'mul_ok1' ... the equivalent intprops.h function > 'mul_ok2'. > > #include > #include > > _Bool > mul_ok1 (long int a, long int b) > { >long c; >return safe_mul (&c, a, b); > } > > _Bool > mul_ok2 (long int a, long int b) > { >long c; >

Re: checking against signed integer overflow

On Sat, Dec 5, 2020 at 1:07 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > You might also checkout an overflow library. For the C language, > > safe_iop is available. > > Gnulib's INT_*_WRAPV macros are similar. [1] > > > -ftrapv is for defective programs. A program using -ftrapv is still >

Re: checking against signed integer overflow

On 12/5/20 8:43 AM, Jeffrey Walton wrote: I also have some GCC inline assembly one-liners that I use on occasion. The good thing about inline assembly is, ASM does not suffer C's undefined behavior. Although asms are occasionally used in Gnulib, they are a maintenance hassle and aren't needed

Re: checking against signed integer overflow

On 12/5/20 10:07 AM, Bruno Haible wrote: Jeffrey Walton wrote: For the C language, safe_iop is available. Gnulib's INT_*_WRAPV macros are similar. [1] Similar, but more portable, as safe-iop requires things like ({...}) and typeof that the Gnulib macros don't assume. Also, safe-iop genera

Re: checking against signed integer overflow

Jeffrey Walton wrote: > You might also checkout an overflow library. For the C language, > safe_iop is available. Gnulib's INT_*_WRAPV macros are similar. [1] > -ftrapv is for defective programs. A program using -ftrapv is still > defective and should be fixed. You mean, '-fwrapv' is for defecti

Re: checking against signed integer overflow

On Sat, Dec 5, 2020 at 10:04 AM Bruno Haible wrote: > > ... > Now, let me ask the question "What compiler options would a distro have to > provide, in order to globally enable signed integer overflow checks?" > (like -D_FORTIFY_SOURCE=2, which many distro vendors now use). > > Through some experim

Re: checking against signed integer overflow

Hi Paul, According to the Gnulib documentation, our recommended way to check against signed integer overflow is to use the INT_*_WRAPV or INT_*_OVERFLOW macros. However, in the discussion about idx_t you mentioned that the benefit of using signed integer types is that one can have the overflow ch