"One of these days everyone is going to know that Clint Eastwood is the biggest Yellow Belly in the West!"  Right?  So even though "I have a bad feeling about this!", it isn't all that bad, unless it is actually worse.  Earlier, while working on the port of UCSD Pascal for the Parallax P2 and other platforms, I came across this mess, in the original Pascal - which I mentioned actually hints at a zero-day issue for many a system.  Which of course presents an ethical conundrum, even if this is HACKADAAY, i.e., in terms of "ethical disclosure."  Well, in any case here is the offending code:

BEGIN (* INSYMBOL *)
   IF GETSTMTLEV THEN
    BEGIN
       BEGSTMTLEV := STMTLEV;
       GETSTMTLEV := FALSE END;
       OP := NOOP;
 1:    SY := OTHERSY;
(* IF NO CASES EXERCISED BLOW UP *)
   CASE SYMBUFP^[SYMCURSOR] OF
   '''':STRING;
   '0','1','2','3','4','5','6','7','8','9':
        NUMBER;
   'A','B','C','D','E','F','G','H','I','J','K','L','M',
   'N','O','P','Q','R','S','T','U','V','W','X','Y','Z',
   'a','b','c','d','e','f','g','h','i','j','k','l','m',
   'n','o','p','q','r','s','t','u','v','w','x','y','z':
        IDSEARCH(SYMCURSOR,SYMBUFP^); (* MAGIC PROC *)
ETC ...

 Now apart from inefficiency, what harm could there be in an otherwise "harmless little case statement" (insert Monty PYTHON quote here) which has a separate case for every letter of the alphabet, so that it probably compiles to an if then else chain with at least that many branches?  Answer:  Besides being inefficient in and of itself, on a modern system, this coding style causes the cache lines to flush every single time, so that code that could have been run out of L1 cache might get run out of L2, or maybe L3 if you are lucky, or maybe on some memory starved systems it will trigger a page fault every single time. 

Then besides 'nerfing the cache lines;  chances are each time through the chain the branch will be taken or not taken at a different point so that the branch predictor on any modern CPU (that has one) will get it wrong - every single time, contributing to further inefficiencies, and therefore so also setting the stage for new, not yet fully imagined MELTDOWN or SPECTRE type attacks; where even if a remote attacker can't steal passwords by analyzing the time to respond to millions of DNS requests over a network - just by listening in to other traffic, i.e., that is by devising a passive packet sniffing strategy that works by putting the "man" in the middle in the form of an otherwise seemingly well-behaved router.  

How knows?  Maybe they can.  Regardless, this still sets the stage for other shady dealings like carefully crafting and DDOS (denial of service), whereby the rogue actor - "the unicorn" is  "in the garden" so to speak, even if the DDOS actually gets routed through Torrents, to that it appears to be inseparably co-mingled with legitimate traffic, and that is how someone could, in principle - do a carefully planned DDOS against certain BGP infrastructure - and take down DNS.

Now if just like "Wall Street", the "circuit breakers trip", and the LRU caches flush - well, that is one variation, and thus the "reindeer games" continue.

Now I wasn't going to say anything about this - but - well, maybe I changed my mind after another bad patch Tuesday because of the "big company"  with "the small name", on the one hand, and not just because some people still can't FACE the music on the other hand.  But now, you know who in the aforementioned has 'nerfed the whole AMD Ryzen line, with some kind of "oops", exposing yet another critical flaw.

Whatever happened to coding standards?  Or testing?  

P.S. For a good time (or not-so-good time) Google the phrase for a paper published by the Linux Foundation entitled "Vulnerabilities in the Core" if you haven't heard about it already.  I found out about it by reading content linked to another article on the HACKADAY Blog.

Mind Boggling!  Time travel anyone?  Temporal Paradox?  Or something else?  Like I said, something else ...