[PATCH] datatrak.c: don't use POSIX %m format for sscanf() in dtrak_prepare_data()

[Lubomir I. Ivanov]

From: "Lubomir I. Ivanov" 

The format option "%m" doesn't work for MINGW/Windows and is reported as
an unknown conversation type and this sscanf() call would not work.

The alternative is to malloc() enough space manually - e.g.
strlen(input) + 1.

Signed-off-by: Lubomir I. Ivanov 
---

Salva, please have a look if you have a minute to verify my change
as i don't know how to test this code.

strdup() should be another way of doing it, given
we aren't doing any parsing - e.g. ignoring digits with:
%[A-Za-z]
---
 core/datatrak.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/core/datatrak.c b/core/datatrak.c
index e61e5c1..2f827c1 100644
--- a/core/datatrak.c
+++ b/core/datatrak.c
@@ -115,7 +115,8 @@ static int dtrak_prepare_data(int model, device_data_t 
*dev_data)
while (model != g_models[i].model_num && g_models[i].model_num != 0xEE)
i++;
dev_data->model = copy_string(g_models[i].name);
-   sscanf(g_models[i].name,"%m[A-Za-z] ", &dev_data->vendor);
+   dev_data->vendor = (const char *)malloc(strlen(g_models[i].name) + 1);
+   sscanf(g_models[i].name, "%[A-Za-z] ", (char *)dev_data->vendor);
dev_data->product = copy_string(strchr(g_models[i].name, ' ') + 1);
 
d = get_descriptor(g_models[i].type, g_models[i].libdc_num);
-- 
1.7.11.msysgit.0

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: smtk2ssrf web service

[Robert Helling]

Salvador,

> On 7. Jun 2017, at 12:35, Salvador Cuñat  wrote:
> 
> Good morning Robert and Pedro.

did you see my pull request on GitHub? Essentially it uses QCoreApplication 
instead of Application and does not initialise a window when operating in 
command line mode.

How confident are you that I cannot get in trouble by running this tool on 
(possibly evil) user supplied input? Does it fail gracefully? Do you have any 
intuition?

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile Bluetooth download

[Jan Mulder]

On 05-06-17 17:49, Dirk Hohndel wrote:

On Mon, Jun 05, 2017 at 05:40:10PM +0200, Jan Mulder wrote:

On 05-06-17 16:41, Dirk Hohndel wrote:

We learned from HW that this should never be the case with production
OSTC. Hmm. Not sure what to do here... that's a generic ID for the chip
they used - not sure if it's smart to assume that's an OSTC. But maybe
that's what we should do? Or we need another UI to pick the device...

I think we need another UI to pick the device anyhow (unfortunately). For
example, for divers that  that use more than one BT dive computer, or in the
special cases that automatically checking of a long list of paired BT
devices fails.

I think I have an idea how to do that, actually... we could create a
"virtual" vendor "Paired BT Devices" and then as "products" we could have
the paired devices... I'll play with that idea.

/D



Ok, I followed up on the forTomaz branch to see if the idea with a 
virtual vendor and a set of paired devices could work. I have things 
partly working (not commit ready yet). I see, however, a fundamental 
problem with this strategy. In order to do a correct dc_device_open, we 
need a real vendor/product pair, and that data is not coming from a 
paired BT device. In fact, when we could construct a real vendor/product 
pair from only BT discovery data, we wouldn't need a virtual vendor in 
the first place.


Obviously, we could construct logic to translate a BT name to a 
vendor/product pair and attach that data to virtual vendor/paired device 
(and basically we need this anyhow to do automatic discovery of DCs), 
but that still does not enable downloading from a paired BT device of 
which we could not determine the real vendor/product pair (but would 
enable downloading from more than one BT DC from one client).


Concluding, I am a bit stuck ...

--jan

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: smtk2ssrf web service

[Robert Helling]

Hi,

> On 7. Jun 2017, at 11:36, Robert Helling  wrote:
> 
>  also silenced some other output

that was overambitious. In fact, I silenced any output. So, now, it always 
returned empty files. Fixed that. Now your file as well as that of Alessandro 
appear to work.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Galileo 2 (G2)

[Linus Torvalds]

On Fri, Jun 9, 2017 at 4:58 AM, William Perry  wrote:
> Several folks from the shop are diving them in Cozumel this week.   If you
> need tests run against a variety of dives (all recreational) I can borrow
> them and run whatever is necessary from mac or Linux.

The more testing, the merrier.

My pool dive only tested the very basics: it does have depth and
temperature data, but no events, no cylinder pressure, no heartrate
monitor etc.

That said, just the fact that all of that showed up on the very first
try (ok, blush, *second* try, because the first try I had entirely
missed filling in any model number at all) does imply that it very
much is the same protocol as the Galileo Sol, except just with a
different transport layer. So it probably gets most things right.

There might be real differences that show up much later - the Uwatec
Smart backend in libdivecomputer has a "GALILEO" vs "GALILEOTRIMIX"
model number and I might have expected the G2 to be the trimix version
because it supports it, but I'm not seeing any actual differences in
parsing between the two.

An maybe it has new events or warnings or whatever. And maybe I just
screwed up the downloading and it just happens to work for one dive
but will completely break immediately when there are more dives. But
on the whole I think that it should JustWork(tm).

But testing it is the only way.

I don't think that I'm going to actually push out my patch to the
official Subsurface libdivecomputer branch until it gets some more
testing than that one trivial pool-dive-on-a-string, so you do have to
build your own for now for testing.

After next week, I should have much more confidence whether it
actually *really* works,  and I'll push it out and maybe we'll have
daily builds that just work with the Scubapro G2 out of the box. But
in the meantime it's a "please test if you can".

Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Galileo 2 (G2)

[CZS]

Linus,

This is fantastic news!  Thank you for the hard work.  

On Friday, June 9, 2017 at 12:28:53 AM UTC-5, Linus Torvalds wrote:
>
> On Wed, Jun 7, 2017 at 8:17 AM, CZS > 
> wrote: 
> > 
> > Thanks for the reply, it's never a bad thing when the developer is 
> diving 
> > the same computer ;)  Great to hear you're working towards a USB 
> download 
> > first, as frankly I find the BLE support a mere luxury! 
>
> So it turns out that the Scubapro G2 support looks really 
> straightforward, helped by the fact that the USB HID part of the thing 
> is very similar to what the Suunto EON Steel does (and I did the 
> reverse engineering for that one, and wrote the downloader), and the 
> actual commands and data parsing appears pretty much exactly the same 
> as the Galileo Sol. 
>
> So if you actually build your own, here's a patch to libdivecomputer 
> that should get things into testable territory. 
>
> I *have* actually tested it myself, but right now my only "dive" is me 
> dropping the dive computer into the neighbors pool for four minutes. 
> So my test data is very very limited. 
>
> I'll have more test data in a week, but for now this might be good 
> enough to do at least some initial trial downloads. 
>
>   Linus 
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Scubapro Galileo 2 (G2)

[William Perry]

Several folks from the shop are diving them in Cozumel this week.   If you
need tests run against a variety of dives (all recreational) I can borrow
them and run whatever is necessary from mac or Linux.

-bill

On Fri, Jun 9, 2017 at 1:29 AM Linus Torvalds 
wrote:

> On Wed, Jun 7, 2017 at 8:17 AM, CZS  wrote:
> >
> > Thanks for the reply, it's never a bad thing when the developer is diving
> > the same computer ;)  Great to hear you're working towards a USB download
> > first, as frankly I find the BLE support a mere luxury!
>
> So it turns out that the Scubapro G2 support looks really
> straightforward, helped by the fact that the USB HID part of the thing
> is very similar to what the Suunto EON Steel does (and I did the
> reverse engineering for that one, and wrote the downloader), and the
> actual commands and data parsing appears pretty much exactly the same
> as the Galileo Sol.
>
> So if you actually build your own, here's a patch to libdivecomputer
> that should get things into testable territory.
>
> I *have* actually tested it myself, but right now my only "dive" is me
> dropping the dive computer into the neighbors pool for four minutes.
> So my test data is very very limited.
>
> I'll have more test data in a week, but for now this might be good
> enough to do at least some initial trial downloads.
>
>   Linus
> ___
> devel mailing list
> de...@libdivecomputer.org
> http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Overthinking on Subsurface mobile app UX

[Davide DB]

On 9 June 2017 at 10:37, Tomaz Canabrava  wrote:

> Davide,
>
> Thanks for the detailed info, That's really really userfull. I'm doing
> what I can here and I think I'll have 4 days of work next week where I can
> actuallly implement something.
>
> Tomaz
>
>>
>>
Ok, no problem at all, even if you don't have the time to work on them,
your thoughts on github would be very appreciated. Maybe I put too much on
the plate.
I found comments on google docs not very ergonomic so I thought it was
better to split the document in several topics on github. Every single idea
is more manageable and traceable.

Bye

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Overthinking on Subsurface mobile app UX

[Tomaz Canabrava]

Davide,

Thanks for the detailed info, That's really really userfull. I'm doing what
I can here and I think I'll have 4 days of work next week where I can
actuallly implement something.

Tomaz

On Thu, Jun 8, 2017 at 3:19 PM, Davide DB  wrote:

> On 3 June 2017 at 15:23, Davide DB  wrote:
> > I had some spare time so I thought to write some suggestion on the
> > dive list fonts. Then I added other considerations on different
> > aspects of the app UX.
> >
> > There are a lot of screenshots, email is not the best media for this
> > kind of things so I wrote everything on Google docs.
> >
> > I hope it helps
> >
> > https://docs.google.com/document/d/1yFIMsHj5CTnpo7WLN0sVd5VxRyeeS
> mXi34BNUF1S0CA/edit?usp=sharing
> >
>
> Ladies and gentlemen, by overwhelming demand :) I split all my suggestion
> on Github:
>
> Mobile UI #1: general layout
> 
> Mobile UI #2: default action for main screen button
> 
> Mobile UI #3: Dive list item layout
> 
> Mobile UI #4: Dive list different layouts and menu option
> 
> Mobile UI #5: sidebar
> 
> Mobile UI #6: Dive detail title
> 
>
> Maybe one day a programmer will find the will to work on mobile UI and
> this could be a starting point, at least.
>
> Let's go dive
>
> --
> Davide
> https://vimeo.com/bocio/videos
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface