On 13.12.2018 17:09, Mark Phippard wrote: >> On Dec 13, 2018, at 10:53 AM, Michael Pilato <cmpil...@collab.net> wrote: >> >>> On 12/13/18 10:45 AM, Branko Čibej wrote: >>> Uh. I forgot about the malfunction handler. However this doesn't really >>> help, other than putting possibly sensitive paths into the crash handler >>> info? We really shouldn't do it this way, users *will* just copy and >>> paste the output tot he 'net. >> Ahem. What Grandpa *meant* to say was: >> >> "Oh, cool! So there _is_ a way to report the non-canonical path. >> Thanks for figuring this out, Julian! Unfortunately, it comes at a >> cost, namely that of revealing potentially sensitive paths in the output >> which I strongly suspect will get copied and paste to the 'net. If we >> could mitigate that part of it, this might turn out to be truly beneficial." >> >> ;-) > Honestly, it seems like complete FUD to me and trying to save face or just be > obstinate. > > FWIW, I agree with Stefan on all of this. We should not be doing abort from > a library. Whether TSVN could do more to avoid it seems like a separate > issue. I do not see why the library cannot just return a useful error and > allow the caller to handle it.
Backwards compat dictates that we can't change the signatures of those functions. We can write new ones with different signatures and deprecate the old ones. Or rather "they" because I'm not volunteering for the code churn and related backporting fallout. That's not stopping anyone else from having a go. -- Brane
