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]
