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
Those all look good to me.
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
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
In rereading that change, I noticed that there's already a section "Target
Platforms" in the Gnulib manual that's a better home for the new material. I
installed the attached patch to move it there.
>From 2aae1301ef698a189d02e842b344841d83b5c352 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: S
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;
>
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
>
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
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
On 12/4/20 12:47 PM, Bruno Haible wrote:
The currently sold Unisys ClearPath Dorado
machines contain Xeon processors.
They're Xeon processors but they come with Unisys-supplied firmware that emulate
the older architectures, which means that C programs on these platforms should
follow the old
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
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
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
Here are a couple of proposed patches, to make use of idx_t instead of ptrdiff_t
when the value is always nonnegative. This helps understanding the code.
2020-12-05 Bruno Haible
filenamecat-tests: Use idx_t for nonnegative ptrdiff_t variables.
* tests/test-filenamecat.c: Inclu
Hi,
Thanks Bruno for your clarifications and the tentative workaround.
Actually it didn't fully work. It certainly helped solving the armadillo
#pragma problem but eventually I got a bunch of undefined references or
even unresolved functions at link time:
undefined reference to `std::basic_i
15 matches
Mail list logo
