esa

I was trying not to spoil that a |= b and a = a | b have different semantics though, as that pretty much winds up giving away the answer IMO

I didn’t have previous exposure to that exact syntax either, but:

• Python and plenty other languages have assignment variations with an operator like +
• | in plenty of languages means logical OR
  • possibly bitwise, but that seems unlikely in Python
• Dicts are sorta complex siblings of sets
• In terms of sets, OR is equivalent to a union

Hence, a |=b should have the same meaning as a = a | b or a = a.union(b)

and then the quiz is about basically implementation details and what the actual semantics winds up being in a language like python, where stuff is mutable by default and references are implicit (even though the zen of python states a preference for being explicit)

I’ll admit I have no idea what makes one of the Rust implementations preferable over the other. Nor can I go looking at the code myself now that GitHub has hosed itself again

There’s also https://github.com/tealdeer-rs/tealdeer

You might want to have a glance at the OpenSSF compiler hardening guide, and maybe try out ASAN (-fsanitize=address).

E.g. I get

[nobody@bb14e99a9c8e cldr]$ ./build/cldr --update --language C.
caution: filename not matched:  ethical-tldr/pages.C./*/*.md

=================================================================
==454==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7fa48a32c0c1 in malloc (/usr/lib/libasan.so.8+0x12c0c1) (BuildId: b8a4241051a1621937fdc46e867ba7ecb56d96ea)
    #1 0x7fa489e8be0f  (/usr/lib/libc.so.6+0x8be0f) (BuildId: 503200d7fda94a5dc6058d7e0694e5d1dcb2e372)
    #2 0x7fa48a2f2761 in vasprintf (/usr/lib/libasan.so.8+0xf2761) (BuildId: b8a4241051a1621937fdc46e867ba7ecb56d96ea)
    #3 0x561d84213d8c in strfmt (/home/nobody/cldr/build/cldr+0x6d8c) (BuildId: 2a0f13efc2c9b12a67e7dd810a2cbdfd1866e53d)

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).

Somewhat reminded of @jonah@neat.computer’s general recommendation against GPG (for other reasons than what this talk is about)