mormegil

https://en.m.wiktionary.org/wiki/Appendix:English_contranyms

Tells you exactly what and at which line the problem is?

Syntax error: unmatched thing in thing from std::nonstd::__map<_Cyrillic, _$$$dollars>const basic_string<epic_mystery,mongoose_traits<char>, __default_alloc_<casual_Fridays = maybe>>

Sure, strtok is a terrible misfeature, a relic of ancient times, but it's plainly the heritage of C, not C++ (just like e.g. strcpy). The C++ problems are things like braced initialization list having different meaning depending on the set of available constructors, or the significantly non-zero cost of various abstractions, caused by strange backward-compatible limitations of the standard/ABI definitions, or the distinctness of vector<bool> etc.

Int3 is a special single-byte (CC, if I recall correctly) form of the INT instruction (which is CD imm8, I think) to raise an interrupt. Interrupt #3 is the debugging interrupt, so by overwriting any instruction with CC, you place a breakpoint there.

Beware the DWIM!

In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed delete *$ to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported *$ not found, assuming you meant 'delete *'. It then started to delete all the files on the disk!

http://www.catb.org/jargon/html/D/DWIM.html

It's not as easy as it sounds, sometimes the screens are all wrong!! https://xkcd.com/722/

In a bank we work for, there is a mandatory security training for employees, mandated by the parent supranational. The bank tried to correct the mistakes in the training or at least make the training optional, as the bank provides its own, more correct program. Rejected by the mother company, mandatory training is mandatory, even if it is wrong.

When you're saying Unix time does not include leap seconds, you are making exactly the wrong conclusion. Unix time is not a monotonically increasing number of seconds since the Epoch, because it excludes those seconds which are marked as leap seconds in UTC. I.e. the time between now and the Epoch was larger than the current Unix time shows (by exactly the number of leap seconds in between). See e.g. https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

Well... unless you measure the number of [milli]seconds using something like time_t, which lies because of leap seconds. I.e. even such a seemingly simple interface, in fact, includes a calendar.

That's against the terms of math :-)

Obligatory: https://xkcd.com/1683/

Yeah, it's working now for me as well, probably just some temporary problem.