It isn't readable with the very light background.
Which Windows versions this should be used on is a guess right now.
So far Windows 7 or newer, but that may need adjustment.
Fixes#935
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
for some reason sometimes activating the dive via tab
or enter gave us the wrong column, so simply select the
right one.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Otherwise we are creating the local git cache path with the remote
variable being uninitialized - which can cause crashes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The number of dives didn't go up, but we have one (or more) additional
dive computers added to an existing dive.
Fixes#936
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user has no default filename set and starts Subsurface without a
filename, the directory that is opened with Save as ends up being the
current working directory of the executable, which might be its
installation directory - which in general is not a good place to save data
files to.
With this change we pick the directory which is usually used for the
default file, which should give us reasonable places on all OSs.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I managed somehow to miss-read and by accident told Linus that the
timestamp was signed.
It is a unsigned uint32_t, so this corrects the mistake i tricked Linus
into making.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When run with -v option, this prints local file names like the path
to the local git repository and the hash file.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With commit b26e516e2a ("Dive_sites-Notes shouldn't be stored as
attribute") our output format changed slightly. Adjust the expected output
to match that change to ensure that TestParse passes again.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Reverting commit 3d8e5b638a makes the CVA
calculation marginally less conservative, and one of the tests fails as a
result. This tiny adjustment to the conservatism fixes that.
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This reverts commit 3d8e5b638a.
Calculating the next gradient should be based on the tissue loading at the end
of the previous iteration, so it was wrong to restore the deco state first.
This has a tiny affect on the calculated profile, and makes one of the tests
fail.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If so, some formatting chars (like "\n") will be dropped while parsing.
This could be pretty annoying for a user who tries to keep notes other
than a simple text, e.g. if the site is a wreck, may be interesting to
have some data shown like:
...
Max. Depth = 60 m
Min. Depth = 40 m
Prow: bla, bla, bla.
Stern: bla, bla, bla.
...
instead of a single text line.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
ACKed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the dive computer tells us that this was free diving we should be a lot
more aggressive splitting dives. For scuba dives a minute seems more
reasonable (to avoid splitting dives when you pop to the surface to get
the bearing and continue the dive after a few second).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Oops. Moving the check to the beginning of the function in order to avoid
partial execution in commit 69036a1bb7 ("Avoid resource leak by bailing
early") had a nasty side effect. Since Linus used 'i' both to hold the
dive number and as a loop variable, by moving this to the top of the
function the dive nr was overwritten which caused all kinds of problems.
My bad - but of course you shouldn't mix loop variables with meaningful
variables, either...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So Anton Lundin says that the 32-bit timestamp for the Divesoft Freedom
is indeed a signed offset from Jan 1, 2000.
This does that, but also extracts the whole thing into a helper function
and makes sure that there are no overflows at any point by using
"timestamp_t" in the whole series, and all the operations are "obviously
safe" in their types (ie no "unsigned char gets widened to 'int' and
then we shift it left by 24 bits").
Signed-off-by: Linus Torvalds <torvalds@linux-fundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While in the current use this won't happen, if someone were to call
split_dive_at with a dive that's not in the dive_table, let's bail right
away before doing any work.
Coverity CID 1325517 1325518
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While the visual state didn't show it, our internal tracking of the
selected state was copied causing all kinds of unexpected behavior. With
this commit we get this right.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commit 31fb2e4c62 ("Avoid possible sign extension") handled the
problem when a "unsigned char" is shifted 24 bits left, and becomes a
"signed int". By casting the result to uint32_t, that signed case won't
happen.
However, there were two bugs in that fix.
The first is the comment. It's not that "timestamp_t" is signed that is
the problem. No, the problem is inherent in the C expression
(ptr[11] << 24)
where "ptr[11]" is an unsigned char. In C arithmetic, unsigned char is
implicitly type-expanded to "int", so while it has a value between
0..255, when you shift it left by 24, you can get a *negative* "int" as
a result.
So it's actually "ptr[11]" that should have been cast to "unsigned", but
it so happens that you can do all the shifting and adding in "int", and
then cast the end result to "uint32_t" and you'll get the same value.
But at no point did "timestamp_t" matter.
The other bug was pre-existing and just not fixed. When the code does
the "+ 946684800" (to turn the timestamp to be seconds from the start of
2000, into seconds since the "unix epoch", ie 1970) that arithmetic is
now done in that "uint32_t" (and used to be done in "int").
Which means that the addition can overflow in 32 bits *before* it is
cast to timestamp_t (which is 64 bits).
Admittedly that 32-bit overflow happens a bit later than the sign bit
gets set, but if we're worried aboout overflows, let's just do this
right.
In other words, we have a 32-bit unsigned offset since Jan 1, 2000, and
for the full range we need to do the epoch correction in 32 bits.
Because otherwise you fail in the year 2106 (32-bit unsigned unix epoch
time limit), even though the 32-bit seconds *should* work all the way
until the year 2136.
Of course, I'll be rather surprised if people still use the Divesoft
Freedom in the year 2106. Or rather, I won't be surprised, because I'll
be dead.
But if we think that the signed problem matters (in the year 2068), then
dammit, we can extend it another 30 years.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This case should be impossible to hit - but this seems better than
assuming this can never happen.
Coverity CID 1325458
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When calling merge_two_dives both dives should be in the dive list so i
and j should never be -1. But just as extra precaution, bail if that's the
case (so that the helper functions below aren't called with negative
indices).
Coverity CID 1189514
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems a false positive, reply is always set before it is used, but
there's no harm in setting it explicitly.
Coverity CID 1325280
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we delete dives that were part of a trip, that trip may get deleted as
well. So if we undo that operation we need to bring back the trip, too.
This also deals with a bug in the original code that did the delete both
in calling code (in divelistview.cpp) and in the redo function. Because of
the nature of the delete this didn't really matter but it is of course
wrong and with the new code it would in fact cause an issue.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Right now this requires that
(a) the dive have only one divecomputer associated with it.
Trying to split a dive with multiple dive computers would be *much*
harder to do, since you'd have to try to line up the surface
interval between computers etc. So just don't do it after
downloading multiple dive computers for the same dive.
(b) there must be at least one minute between the sample that came up
to the surface and the sample that goes down again.
If you just peeked your head above the surface, don't try to split
things into two dives. Maybe we can relax this for freediving or
something.
also note that the split dive will only get new numbering if the dive
that was split was the very last dive in the divelist.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We only made sure the divelist allocation was big enough in
"record_dive_to_table()", but add_single_dive() can add entries too.
Now, in practice that never bit anybody, since
(a) we allocate extra entries anyway, and it would be very unusual that
the divelist table was exactly full
(b) most "malloc()" implementations end up having their own slop on top
of that
(c) add_single_dive() was only used for merging dives, which actually
ends up removing more divex than it adds (but it does add one first)
but when I'm starting to split dives, this will be a bigger issue in
practice. And it was wrong.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the code more robust in case the Uemis returns random or
non-sensical data. It's unlikely the user has a billion dives or that the
Uemis returns such a number. That's no reason not to handle this case
without crashing.
Coverity CID 1325289
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I actually think this might be a false positive, but the libgit2 API
doesn't appear to guarantee that ancestor is not NULL, so let's add that
check.
Coverity CID 1325296
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This looks like possibly a false positive in the Coverity scan, but we can
always assume that the first point of the dive plan has been entered by
the user.
Coverity CID 1325285
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
