Thread overview
[Issue 11188] std.math.abs fails for shared BigInt type
Sep 18, 2017
b2.temp@gmx.com
Sep 20, 2017
anonymous4
Sep 21, 2017
Simen Kjaeraas
Sep 21, 2017
anonymous4
Sep 27, 2017
Simen Kjaeraas
Mar 21, 2020
Basile-z
September 18, 2017
https://issues.dlang.org/show_bug.cgi?id=11188

b2.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com
            Summary|std.math.abs fails for      |std.math.abs fails for
                   |shared, const or immutable  |shared BigInt type
                   |BigInt types                |

--- Comment #10 from b2.temp@gmx.com ---
Only valid for shared nowadays

import std.bigint, std.math, std.typetuple;

auto foo(T)()
{
    T n = -3;
    return std.math.abs(n);
}

void main()
{
    foreach (T; TypeTuple!(byte, short, int, long, BigInt))
    {
        assert(foo!T() == 3);             // works
        assert(foo!(shared(T)) == 3);     // fails for BigInt
    }
}

The problem is that operator overloads don't accept shared

void main()
{
    import std.bigint;
    shared(BigInt) i = 0;
    assert(i >= 0);
}

--
September 20, 2017
https://issues.dlang.org/show_bug.cgi?id=11188

--- Comment #11 from anonymous4 <dfj1esp02@sneakemail.com> ---
I think concurrency support is unreasonable here (and lacks rationale and use case). How it would work? Create a mutex for every BigInt?

--
September 21, 2017
https://issues.dlang.org/show_bug.cgi?id=11188

--- Comment #12 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
(In reply to anonymous4 from comment #11)
> I think concurrency support is unreasonable here (and lacks rationale and use case). How it would work? Create a mutex for every BigInt?

BigInt internals are immutable, and abs takes its argument by value, so no mutex is necessary.

For anyone who wants to fix this, the problem is not actually in std.math.abs, but in BigInt - its operator overloads are not shared-aware.

--
September 21, 2017
https://issues.dlang.org/show_bug.cgi?id=11188

--- Comment #13 from anonymous4 <dfj1esp02@sneakemail.com> ---
Indeed, but it's still big and shallow mutable. How would you avoid tearing? It suggests different data layout with increased pressure on GC.

--
September 27, 2017
https://issues.dlang.org/show_bug.cgi?id=11188

Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #14 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
True - access to the BigInt would need to be protected somehow, and letting abs(shared BigInt) simply compile without warning signals to the user that it's perfectly safe, while tearing could still happen (unsynced ptr/length for the data field, or wrong sign). The way shared works in D today, it's simply the wrong choice. Thanks for enlightening me! :)

Closing this issue as wontfix because while important parts of the original issue are fixed, the current name indicates shared only, and forcing the user to cast (and thus hopefully think about locking or otherwise limiting access).

--
March 21, 2020
https://issues.dlang.org/show_bug.cgi?id=11188

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|b2.temp@gmx.com             |

--