On Wednesday, 7 August 2019 10:19:01 PDT Linus Torvalds wrote:
> Again, truncation of long to int isn't undefined behavior or overflow.
> It's just a value truncation.
Strictly speaking, it's defined only if the result fits. Otherwise, the C
standard says it's implementation defined what
On Wednesday, 7 August 2019 09:31:35 PDT Linus Torvalds wrote:
> > 2) Make pressure_t (and related variable) int64_t,
>
> Absolutely not. See above. That would be entirely crazy.
Unless you want to use Subsurface to calculate a dive into the core of the Sun
(pressure there is estimated at
Linus,
> On 7. Aug 2019, at 20:21, Linus Torvalds
> wrote:
>
> Ahhah! Caught it.
thanks a lot for figuring this out! In my testing it prevents the total
craziness. I think negative pressure in themselves are not a bug as long as the
user is informed what they indicate. I sent a patch to
On Wed, Aug 7, 2019 at 10:31 AM Linus Torvalds
wrote:
>
> The planner does most things in floating point, so maybe that's what
> goes on - doing the math in FP and then assigning to an integer.
Ahhah! Caught it.
I hacked up a special version of "ssrf_double_to_int()" that does
range
On Wed, Aug 7, 2019 at 10:19 AM Linus Torvalds
wrote:
>
> I'll play around with narrowing our types (and making them signed) and
> seeing if something pops up.
Nope, no luck there either. No integer overflows in sight.
The planner does most things in floating point, so maybe that's what
goes on
On Wed, Aug 7, 2019 at 10:08 AM Linus Torvalds
wrote:
>
> It might be worth trying a few other gcc options. Things like
> "-fsanitize=undefined" to find general undefined behavior (which
> includes integer overflow, but also other things - but again does
> *not* include the well-defined unsigned
On Wed, Aug 7, 2019 at 10:00 AM Linus Torvalds
wrote:
>
> So using -ftrapv actually works, but may not be practical. But for
> debugging this particular issue, I'll just start with an empty dive
> log and try your planner thing.
Hmm. I can do that, but then I don't see any issue.
And in fact,
On Wed, Aug 7, 2019 at 9:51 AM Linus Torvalds
wrote:
>
> It might be worth trying to just build subsurface with "-ftrapv".
Yeah, that just SIGABRT's immediately for me just from loading my dives.
Apparently I have a dive with
ndl=71582788:15
in my dive log, because that's how we print a
On Wed, Aug 7, 2019 at 9:31 AM Linus Torvalds
wrote:
>
> Now, it is possible that while you're doing some intermediate
> calculations, you might end up having temporary values that are bigger
> than int32_t (say, because you're multiplying millimeters by millibars
> and haven't reduced the range
On Wed, Aug 7, 2019 at 6:42 AM Robert Helling wrote:
>
> The planner tries computes the consumed gas for the dives it plans. It
> computes it in terms of litres of gas. Then, in the end, using the assumed
> cylinder size this is converted into a pressure drop.
>
> As you know, internally, all
Hi,
here is a problem that came up in
https://github.com/Subsurface-divelog/subsurface/issues/2212 that I would like
your opinion on how to address it:
The planner tries computes the consumed gas for the dives it plans. It computes
it in terms of litres of gas. Then, in the end, using the
11 matches
Mail list logo