Re: Hex numbers (e.g. memory addresses) pseudonymising for comparable logging output

Pardon my ignorance.

Are you saying the anonymizing of addresses - which is done for security - is so weak that a simple algorithm can decrypt them?

Or am I missing something?

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

Comment on Re: Hex numbers (e.g. memory addresses) pseudonymising for comparable logging output

Replies are listed 'Best First'.
Re^2: Hex numbers (e.g. memory addresses) pseudonymising for comparable logging output by hippo (Archbishop) on Feb 18, 2022 at 14:12 UTC
ISTM that etj's code simply replaces each address in turn of each run by a numbered placeholder so them being different addresses doesn't ruin his diffs. The addresses within each run are consistent but between runs are not. He isn't decrypting anything, just saying the first address seen will always be ADDR1 and the second ADDR2, etc. Is that clearer or even more confusing? 🦛	[reply]
Re^3: Hex numbers (e.g. memory addresses) pseudonymising for comparable logging output by LanX (Saint) on Feb 18, 2022 at 15:10 UTC
IOW he's identifying identical addresses by the order given in the trace's output to rename them consistently? Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^4: Hex numbers (e.g. memory addresses) pseudonymising for comparable logging output by hippo (Archbishop) on Feb 18, 2022 at 15:15 UTC
Indeed. So if one trace had `0xAAAABBBB 0x33333333 0xAAAABBBB` [download] and another trace had `0xBEEFCAFE 0x99999999 0xBEEFCAFE` [download] They would both end up as `ADDR1 ADDR2 ADDR1` [download] and thus not show up as false positives in the ensuing diff. 🦛	[reply] [d/l] [select]
Re^5: Hex numbers (e.g. memory addresses) pseudonymising for comparable logging output by LanX (Saint) on Feb 18, 2022 at 18:19 UTC