In most cases the existing code might have done the right thing, but some
of the hard to reproduce errors might actually stem from the fact that we
have intermittend fs errors. Maybe this addresses things?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
tissue_tolerance wasn't used after it was assigned.
type was overwritten after it was assigned.
serial was overwritten after the last /= 100.
event is assigned in the for loop.
clear isn't used after the assignment
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I know everyone will hate it.
Go ahead. Complain. Call me names.
At least now things are consistent and reproducible.
If you want changes, have your complaint come with a patch to
scripts/whitespace.pl so that we can automate it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
rint() is "round to nearest integer", and does a better job than +0.5
(followed by the implicit truncation inherent in integer casting). We
already used 'rint()' for values that could be negative (where +0.5 is
actively wrong), let's just make it consistent.
Of course, as is usual for the messy C math functions, it depends on the
current rounding mode. But the default round-to-nearest is what we want
and use, and the functions that explicitly always round to nearest
aren't standard enough to worry about.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Earlier we converted the C++ code to using true/false, and this converts
the C code to using the same style.
We already depended on stdbool.h in subsurfacestartup.[ch], and we build
with -std=gnu99 so nobody could build subsurface without a c99 compiler.
[Dirk Hohndel: small change suggested by Thiago Macieira: don't include
stdbool.h for C++]
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a separate patch because it required more changes
and branches due to how opendir() works on win32
with the separate struct type _WDIR and the according _w...
methods for it.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Adds use of everything from the new wrappers(), but the
opendir() one.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
next_segment():
The iterator limit check (i < size - 1) should precede
the indexing (buf[i]).
Reported by the program cppcheck.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This can happen if the Uemis is not correctly connected, but the user
still has the path set (as default DC most likely) and tries to start a
download.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This may seem like a really odd change - but with this change the Qt tools
can correctly parse the C files (and qt-gui.cpp) and get the context for
the translatable strings right.
It's not super-pretty (I'll admit that _("string literal") is much easier
on the eye than translate("gettextFromC", "string literal") ) but I think
this will be the price of success.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- remove the build flags and libraries from the Makefile / Configure.mk
- remove the glib types (gboolean, gchar, gint64, gint)
- comment out / hack around gettext
- replace the glib file helper functions
- replace g_ascii_strtod
- replace g_build_filename
- use environment variables instead of g_get_home_dir() & g_get_user_name()
- comment out GPS string parsing (uses glib utf8 macros)
This needs massive cleanup, but it's a snapshot of what I have right now, in
case people want to look at it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commit 48ba01b807 ("Enable downloads from the UEMIS Zurich")
mistakenly switched the meaning of the "force_download" argument when it
moved from "struct argument_block" to being a direct argument.
This fixes it right back.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This behaves somewhat differently from the Gtk version - still needs
more investigation. But at least now it's hooked in.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- rip all Gtk code from qt-gui.cpp
- don't compile Gtk specific files
- don't link against Gtk libraries
- don't compile modules we don't use at all (yet)
- use #if USE_GTK_UI on the remaining files to disable Gtk related parts
- disable the non-functional Cochran support while I'm at it
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Most of the warnings are IMHO false positives:
e.g.: an enum variable is initialized in a switch statement that has a case for
each possible enum value - yet gcc 4.8 warns that it could be used
uninitialized;
or: two variables are initialized together in the code - second one of them
is previously initialized to -1 at declaration time, both are initialized
in an if (second one == -1) clause - so they are guaranteed to both be
initialized...
I did not "fix" those as the code is actually correct.
But there are three spots where it catches things that could indeed go wrong
(with odd input data in one of them).
This commit also adds a check to only call g_type_init() for older versions of
glib as in newer ones it is deprecated.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is simplistic & brute force: any function that touches Gtk related
data structures is moved to divelist-gtk.c, everything else stays in
divelist.c.
Header files have been adjusted so that this still compiles and appears to
work. More thought is needed to truly abstract this out, but this seems to
be a good point to commit this change.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A couple of these could clearly cause a crash just like the one fixed by
commit 00865f5a1e1a ("equipment.c: Fix potential buffer overflow in
size_data_funct()").
One would append user input to fixed length buffer without checking.
We were hardcoding the (correct) max path length in macos.c - replaced by
the actual OS constant.
But the vast majority are just extremely generous guesses how long
localized strings could possibly be.
Yes, this commit is likely leaning towards overkill. But we have now been
bitten by buffer overflow crashes twice that were caused by localization,
so I tried to go through all of the code and identify every possible
buffer that could be affected by this.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Uemis SDA returns the data for each dive from several different
databases. And oddly, the getDive data uses a different key than the
getDivelog data. We have always compensated for that by looking up the
correct key and applying the data to that dive, but unfortunately we
didn't adjust the loop to correctly retrieve the getDive data for the
dives that were downloaded. So depending on how big the offset between
those two keys was we wouldn't get all of the necessary data.
With this change we try one, calculate the offset and then restart the
loop. Insane, but appears to be the only way to make this work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If any component of the suit information downloaded from the Uemis SDA is
"" we would replace that by the POT information when running the software
in a different locale. So only add this text (and translate this text) if
it is != "".
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Mostly coding style and whitespace changes plus making lots of functions
static that have no need to be extern. This also helped find a bit of code
that is actually no longer used.
This should have absolutely no functional impact - all changes should be
purely cosmetic. But it removes a bunch of lines of code and makes the
rest easier to read.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This moves the fields 'duration', 'surfacetime', 'maxdepth',
'meandepth', 'airtemp', 'watertemp', 'salinity' and 'surface_pressure'
to the per-divecomputer data structure. They are filled in by the dive
computer, and normally not edited.
NOTE! All actual *use* of this data was then changed from dive->field to
dive->dc.field programmatically with a shell-script and sed, and the
result then edited for details. So while the XML save and restore code
has been updated, all the displaying etc will currently always just show
the first dive computer entry.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since multiple dives can reference the same divesite we need to do the
strdup when the value gets assigned, not when it gets passed into the
helper function.
This also validates the location string as on my divecomputer there is an
invalid divespot 0 that has a corrupted UTF8 string as location name.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In order to work in the most expected ways for people who have used
a version of Subsurface that didn't store the deviceid in the divecomputer
we relax the testing for when a divecomputer entry is assumed to match the
current divecomputer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In commit 194a05b18911 "Correct the detection of existing dives in the
Uemis downloader" I forgot to add that check before calling strcmp.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Sometimes the Uemis appears to return " " as notes instead of no notes.
This patch filters this out (otherwise redownloading divecomputers can
cause silly things like notes that say "(existing note) or ( )" )
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This didn't take multiple divecomputers into account and didn't compare
the model as well as the deviceid to match a divecomputer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When analyzing the buffer that is handed to the first_object_id function
we carefully check to make sure that we don't read past the end of the
input buffer but there was still one code path that could have us do just
that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When starting from the first dive on the dive computer we called getDive
for every dive starting with id 0 instead of figuring out which id is
actually the first one that we downloaded.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This actually makes us internally use 'micro-degrees' for latitude and
longitude, and we never turn them into floating point either at parse
time or save time.
That said, the Uemis downloader internally does still use atof() when
converting things, which is likely a bug (locale issues and all that),
but I'll ask Dirk to check it out.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is improving a bit more on commit d2dd0eb39efe "When starting with an
empty data file and downloading dives, number them" by providing a better
starting number when a user downloads dives from a Uemis SDA into an empty
data file.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way individual pieces can be turned on and off.
The commit also adds code to read from a disk image (instead of the SDA)
without all the long timeouts.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Never make trivial changes without testing them. This was missung a '!'
before the strcmp - so the wrong code got executed when trying to get the
DeviceId and everything afterwards failed without a valid DeviceId.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The initial downloader reused the XML parsing of SDA files that was
implemented early in order to support the information extracted from the
SDA with the java applet. But creating this intermediary XML file and
handing it off to the XML import function always seemed like an ugly way
to do things. This became even more obvious when adding more features to
the Uemis downloader.
This commit completely changes the downloader to instead create dives and
record them directly.
This also adds support for divespots (which are stored in a seperate
database that needs to be queried after the divelog and dive entries have
been combined - the Uemis firmware clearly was written by monkeys on
crack - oh wait: I'm trusting these same people to get the deco right?).
This commit leaves the SDA import capability in the XML parser intact.
I'll remove that later. Because of this it actually adds a few lines of
code, but the overall change will be a substantial code deletion.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Actually, it's even better than that. Thanks to the new divecomputer
datastructure we can now simply look up in the dive_table which dives have
been downloaded from this specific Uemis SDA.
This patch removes the old gconf based code - which leads to one
unfortunate problem: the first time a Uemis SDA owner runs this version of
Subsurface against their data file ALL dives will be downloaded again
(which may not be a bad thing as we have improved a few other details of
Uemis support so now they get their deco information, surface pressure and
other data that we have started to support since 2.1). Still, this is not
ideal. But I didn't want to keep the legacy code around since this new
solution is so much cleaner.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code pretended to support this for libdivecomputer based downloads,
but it had never been hooked up when the native Uemis downloader was
implemented. When I finally decided to close that feature gap I realized
that the original code was, shall we say, "aspirational" or "completely
bogus" and therefore never worked.
So instead of just hooking up the code for the Uemis downloader I instead
implemented this correctly for the first time for both libdivecomputer and
the native Uemis downloader.
In order not to have to mess with multithreaded Gtk development I simply
opted for a helper function that fires on a 100ms timeout and have it end
the dialog without a response. This way we can run the dialog while
waiting for the download to finish, still update the progress bar and
respond in a useful manner to the user clicking cancel.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And again buffer_insert contained the blatant bug.
The code wasn't copying the trailing '\0' when extending the string, which
usually didn't end up blowing up the code (and therefore kept the bug
hidden until now) because of the way realloc reused memory - we just had
trailing garbage strings. But sometimes we weren't so lucky and the strlen
in a subsequent call of buffer_insert would run past the end of the
allocated buffer.
Oops.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We are accessing offset 24 in an array of length 24. To make things easier
for the base64 conversion we just treat this as an off by three error and
instead create an array large enough for 27 elements and convert a
sufficient number of base64 chars to initialize all of them.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
