- devel - libdivecomputer.org

Permanent mirror of repository on GitHub?
by Henrik B A 05 Jan '18

05 Jan '18

Hi Jef. Would you consider creating a permanent & updated mirror of libdevcomputer on GitHub? I like browsing the source code in a browser, and GitHub is such a good tool for doing that. The web interface at http://git.libdivecomputer.org/?p=libdivecomputer.git;a=summary is slow, times out a lot, and is really not very usable. Cheers, Henrik

4 7

V3: Coverity / static analysis based cleanups
by Dirk Hohndel 05 Jan '18

05 Jan '18

Third version of this series. I addressed Jef's comments and dropped both patches that dealt with the dc_buffer code as they did more damage than good. Maybe I'll do a new set of patches just for the buffer code if I feel bored later. /D [PATCH 01/12] Cleanup: correctly handle upper bound of array [PATCH 02/12] Cleanup: avoid memory leaks [PATCH 03/12] Cleanup: avoid memory leak [PATCH 04/12] Cleanup: avoid memory leak [PATCH 05/12] Cleanup: avoid memory leak [PATCH 06/12] Cleanup: ensure string is 0 terminated [PATCH 07/12] Cleanup: avoid undefined shift operation [PATCH 08/12] Cleanup: remove dead code and return the correct return [PATCH 09/12] Cleanup: check return value of ioctl() [PATCH 10/12] Cleanup: consistently check return value of iostream [PATCH 11/12] Cleanup: bail on error [PATCH 12/12] Cleanup: remove confusing NULL check

2 14

V2: Coverity / static analysis based cleanups
by Dirk Hohndel 04 Jan '18

04 Jan '18

This is the second version of a series of 14 patches against the current tip of the Subsurface-branch of libdivecomputer. I believe that all of them should apply to upstream master (but haven't verified that). I have incorporated Jef's feedback on the first version. One change compared to my email responses to that feedback is that I ended up not modifying patch 12/14 (consistently check return value of iostream) as it made the code really ugly and as Jef said, not resetting the timeout doesn't really matter. Linus, based on your feedback and Jef's comment I rewrote 7/14; can you please double check that I didn't mess this up by combining it all in one operation? Happy to get more feedback / comments. Thanks /D [PATCH 01/14] Cleanup: correctly handle upper bound of array [PATCH 02/14] Cleanup: avoid memory leaks [PATCH 03/14] Cleanup: avoid memory leak [PATCH 04/14] Cleanup: avoid memory leak [PATCH 05/14] Cleanup: avoid memory leak [PATCH 06/14] Cleanup: ensure string is 0 terminated [PATCH 07/14] Cleanup: avoid undefined shift operation [PATCH 08/14] Cleanup: remove dead code and return the correct return [PATCH 09/14] Cleanup: dc_buffer_clear() should be a void function [PATCH 10/14] Cleanup: check return value of ioctl() [PATCH 11/14] Cleanup: check error return values of buffer handling [PATCH 12/14] Cleanup: consistently check return value of iostream [PATCH 13/14] Cleanup: bail on error [PATCH 14/14] Cleanup: remove confusing NULL check

3 22

Any interest in a VR3 integration?
by Dirk Niggemann 04 Jan '18

04 Jan '18

I realize that Delta P has been out of business for many years and the vr3 is now positively antique and but was wondering if anybody was still interested in supporting the interface. I was going to have a go at it given that i have all the avialble download software, but was wondering whether there was any intereset anymore. Regards, Dirk Niggemann

2 1

Coverity / static analysis based cleanups
by Dirk Hohndel 03 Jan '18

03 Jan '18

This is a series of 14 patches against the current tip of the Subsurface-branch of libdivecomputer. I believe that all of them should apply to upstream master (but haven't verified that). Some of them are clear bug fixes, some of them are equally clear fixes to avoid memory leaks. A few deal with cases where the current code ignores the return values of functions - that last type I am not always 100% sure about my resolution... All of them were generated based on a Coverity scan of Subsurface, built on Linux. This series should address all of the currently open Coverity issues that aren't rather obvious false positives. As usual, one can argue whether all of these issues are indeed bugs and how they should be fixed (e.g., should we check return values and return errors to our callers, or is it safe to ignore certain errors (in which case that should be done explicitly for consistency)). Happy to get feedback / comments. Thanks /D [PATCH 01/14] Cleanup: correctly handle upper bound of array [PATCH 02/14] Cleanup: avoid memory leaks [PATCH 03/14] Cleanup: avoid memory leak [PATCH 04/14] Cleanup: avoid memory leak [PATCH 05/14] Cleanup: avoid memory leak [PATCH 06/14] Cleanup: ensure string is 0 terminated [PATCH 07/14] Cleanup: avoid undefined shift operation [PATCH 08/14] Cleanup: remove dead code and return the correct return [PATCH 09/14] Cleanup: be explicit about ignoring the return value of [PATCH 10/14] Cleanup: check return value of ioctl() [PATCH 11/14] Cleanup: check error return values of buffer handling [PATCH 12/14] Cleanup: consistenty check return value of iostream [PATCH 13/14] Cleanup: bail on error [PATCH 14/14] Cleanup: remove confusing NULL check

3 28

question about the code
by Dirk Hohndel 29 Dec '17

29 Dec '17

Hi Jef, I'm in the middle of addressing some issues that static code analysis has uncovered in the libdivecomputer code. One of the things pointed out by Coverity is that this piece of code is pretty non-sensical (uwatec_smart.c around line 222): static dc_status_t uwatec_smart_device_close (dc_device_t *abstract) { dc_status_t status = DC_STATUS_SUCCESS; uwatec_smart_device_t *device = (uwatec_smart_device_t*) abstract; dc_status_t rc = DC_STATUS_SUCCESS; // Close the device. rc = dc_iostream_close (device->iostream); if (status != DC_STATUS_SUCCESS) { dc_status_set_error(&status, rc); } return status; } So we set status to DC_STATUS_SUCCESS Then we set rc to DC_STATUS_SUCCESS Then we immediately overwrite rc with the return value of dc_iostream_close Then we test status(!) for being different from DC_STATUS_SUCCESS (which of course it never is as we explicitly set it to that value). Inside that we call a helper function that overwites status, but only if it is not equal to DC_STATUS_SUCCESS And then we return - ta-da! - status. What I /think/ you wanted to write was this: static dc_status_t uwatec_smart_device_close (dc_device_t *abstract) { uwatec_smart_device_t *device = (uwatec_smart_device_t*) abstract; // Close the device and pass up the return code return dc_iostream_close (device->iostream); } Am I missing something here? A patch that fixes this will be included in my patches later today. /D

2 2

Subsurface libdivecomputer branch merged with upstream..
by Linus Torvalds 13 Dec '17

13 Dec '17

So this took many hours and much frustration, but I've got an updated libdivecomputer tree at https://github.com/torvalds/libdc-for-dirk which has the iostream code from Jef's upstream libdivecomputer. I tried very hard to actually make use of the new iostream code, and in fact it does help get rid of one particularly ugly hack of ours: we used to hook into the serial code with a particularly ugly little hack using the RETURN_IF_CUSTOM_SERIAL() macro. We now avoid that, and actually create our own custom iostream for that case, and then the new iostream code does things right. HOWEVER. We don't actually use Jef's "custom" iostream layer for it, and most particularly, we don't actually expose that to the outside. The actual outside interface remains our trusty old "dc_custom_io_t", and the special custom serial case is actually just a trivial wrapper inside libdivecomputer for that. It's only used for the legacy serial emulation (ie notably Shearwater and OSTC). The Scubapro G2 and EON Steel end up using the subsurface dc_custom_io_t model directly, since for them it's not just a serial stream. End result: it all looks ok. I've tested it here with my EON Steel (both BLE and USB), my Scubapro G2 (also BLE and USB) and my Shearwater Perdix AI (BLE only, obviously). But I only pushed to my own "libdc-for-disk" repository, because this is a *big* change, and I'd like at least Dirk to check that it works for his cases too. Jef: I basically ended up using the "custom" approach for just the internal serial emulation. I *considered* just changing your "custom.c" file to make that work for me, but ended up just instead adding a "src/custom_io.c" file instead. It's pretty close to your custom.c file, but it is explicitly designed to interface with our "dc_custom_io_t". As mentioned elsewhere, I don't think your custom implementation actually is usable for outsiders. Dirk - caveat emptor. I think it's all good. It looks sane. It passes my tests. But the diffs to both of the parents in that merge is complicated, and the merge does a fair amount of things that were not in either parent since it only made sense as part of the merged state. I'm actually fairly happy with the end result, but the merge itself was painful enough that you really should check it out. Linus

2 2

[ANNOUNCE] Version 0.6.0 now available
by Jef Driesen 25 Nov '17

25 Nov '17

Hi, The v0.6.0 release is now available! http://www.libdivecomputer.org/releases/libdivecomputer-0.6.0.tar.gz The v0.6.0 release adds support for several new devices, introduces two new features and fixes a couple of bugs. There are a few minor backwards incompatible changes, but most applications won't be affected by those. New features: * Add support for new backends: - g2: Scubapro G2, Aladin Sport Matrix, Aladin Square * Add support for many new devices: - Aqualung: i200, i750TC - Cochran: Commander I, II and TM - Cressi: Drake - Hollis: DG02 - Mares: Quad - Oceanic: F10 - Ratio: iX3M and iDive series - Suunto: D4f, Eon Core - Uwatec: Aladin Tec 3G * Add basic timezone support * Add support for synchronizing the device clock * Document the public api with man pages Removed/changed features: * Remove the deprecated gas change events * Remove the deprecated vendor_product_parser_create(), vendor_product_device_open() and vendor_product_extract_dives() functions from the public api * Remove the hw_{frog,ostc,ostc3}_device_clock() functions Bug fixes: * Many small improvements Jef

1 0

RE: Case #: 8713174786
by devel 21 Nov '17

21 Nov '17

Federal Bureau of Investigation Internet Crime Investigation Center Minneapolis Ste. 1265 132 Washington Ave, West MN 55521 Telephone: +18883089044 Fax: +18883089044 October 22, 2017 Case Number: 8733174167 The IP address registered on your name was referred to the FBI's ICC Center (IC3) multiple times as being a possible suspect of federal cyber crime. Through investigation conducted by the Minneapolis Cyber Division of the FBI your IP address was used to commit several online crimes. This investigation covers the time period from August 3, 2017 to the present. We appreciate your instant attention and cooperation while we are investigating this case. Please contact us urgently , at telephone number listed above. Sincerely, Sam Davis Internet Crime Investigation Center/Cyber Division FBI - Minneapolis Suite 1172 111 Washington Avenue, East MN 55982 Phone: +18883089044 Fax: +18883089044

1 0

Re: Anybody with a Suunto EON Core?
by Jef Driesen 20 Nov '17

20 Nov '17

On 2017-11-20 02:45, Linus Torvalds wrote: > I just pushed out support for the new Suunto EON Core to the > subsurface branch of libdivecomputer, but I don't actually have access > to the hardware, so it's purely based on reporting from Nick Shore. > > It almost certainly "just works" (just different USB device ID and > physical form factor, otherwise identical dive computer), but it would > be lovely to have somebody check and verify.. I also got the info on the new USB PID from Nick, and already made the necessary changes to libdivecomputer. My patch is almost identical to yours. Jef

1 0