Rewriting this would be a huge mistake. There are like four working units left, three of the owners use Subsurface, two of them have carefully hacked the existing code to work for them...
Please don't touch this. It's reverse engineered from a reverse engineered Java app, and then reworked a couple of times. I used to have three of these monsters, they are all dead now /D On April 24, 2024 9:01:31 PM PDT, Berthold Stoeger <[email protected]> wrote: >On Donnerstag, 25. April 2024 02:16:12 CEST Dirk Hohndel via subsurface wrote: >> > On Apr 24, 2024, at 11:44, Linus Torvalds <[email protected]> >> > wrote: >> > >> > On Wed, 24 Apr 2024 at 11:13, Dirk Hohndel via subsurface >> > >> > <[email protected]> wrote: >> >> Those with better skills in interpreting error messages... what am I >> >> missing?> >> > I think the line numbers are wrong, probably because of inlining etc. >> >> > The real issue is _probably_ on line 525: >> I don't think you are correct... I got fooled by the weird error output. >> The real error is in line 290: >> [...] > >Incidentally, I just started reworking uemis-downloader.cpp and uemis.cpp. > >I think the correct fix is to simply not use snprintf() et al., but instead >use std::string >instead. This makes things so much clearer for everybody (including the >compiler). printf- >style formatting is fundamentally broken. > >Concerning uemis-downloader.cpp, I noticed an odd thing: there is a "newmax" >variable >that contains an integer formatted as a string(!). > >The memory for that string is allocated in uemis_get_divenr(). The owner of >the memory >seems to be do_uemis_import() (who never frees it, by the way). However: > >1) do_uemis_import() passes "newmax" as "char *" to get_matching_dive() (i.e. >with "value >semantics"). > >2) get_matching_dive() then passes a pointer to the local "newmax" (char **) >to >process_raw_buffer() (i.e. with "reference semantics"). > >3) process_raw_buffer() may reallocate the string and overwrite "newmax". > >The problem: only the local version of newmax in get_matching_dive() is >overwritten. >do_uemis_import() still has a pointer to the now free()d memory. > >Am I missing something? Can you shed some light on this? > >I would suggest to replace "newmax" by an integer variable. But should that be >passed >using value or reference semantics from do_uemis_import() to >get_matching_dive()? > >Berthold
_______________________________________________ subsurface mailing list -- [email protected] To unsubscribe send an email to [email protected]
