There were a number of fprintf()s that escaped the conversion
to report_info(), because they used "debugfile" instead of
"stderr" as target. However, debugfile was just #defined to
be stderr, so we might just use report_info() for consistency.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The uemis code is wild. It simply doesn't deallocate memory
and uses global variables. To get this under control, create
a "struct uemis" and make the functions exported by "uemis.h"
members of "struct uemis". Thus, we don't have to carry around
a parameter for the state of the importing process.
Turn a linked list of "helper" structures (one per imported dive)
into a std::unordered_map, to fix leaking of the helper structures.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Convert some C-style strings in uemis-downloader.cpp to std::string.
This has the side effect of fixing builds on Debian Trixie, which
currently fail with the (rather silly) error:
/build/subsurface-beta-202405060411/core/uemis-downloader.cpp: In function 'char* build_ans_path(const char*, int)':
/build/subsurface-beta-202405060411/core/uemis-downloader.cpp:290:32: error: '%s' directive output between 0 and 12 bytes may cause result to exceed 'INT_MAX' [-Werror=format-truncation=]
290 | snprintf(buf, len, "%s/%s", path, name);
| ^~
......
529 | ans_path = build_filename(intermediate, fl);
| ~~
cc1plus: some warnings being treated as errors
Signed-off-by: Richard Fuchs <dfx@dfx.at>
