Perl code that is syntactically correct only on Fridays

It couldn't fail at his desk, because he ran both servers locally while developing. And it wouldn't fail in production in the morning, since we had a cron job that synced the clocks at midnight. It took until after 5pm for the clocks to drift enough, meaning I was on call and the intern was not.

But the bug didn't crop up until his code had been in production for a couple of weeks, so it was a real pain in the neck to track down.

Since developers rarely worked late and would give up when hitting the "random" test suite failure and go home, the bug persisted for months before the true cause was understood.

Our time zone was UTC-5, and the test suite contained a local-vs-UTC bug which only triggered between 7pm and midnight.

What is the best way to set or mock system time during testing?

What is the "#/+" for?

> # but on other days causes the interpreter to trigger a syntax error

You have this the opposite way round to what's happening (and the description). It only compiles on a Friday, i.e. when the sub takes no arguments.

Removing all the "only on a Friday" stuff boils down to the difference between these two:

    # this compiles
    sub f() {}
    f/1;#/+

    # this doesn't compile
    sub f {}
    f/1;#/+

    sub f {}
    f /1;#/;

However, when the sub does accept args, `f <stuff>` tries to compile `<stuff>` into arguments to send - and it's a regex pattern `/.../` so the # isn't a comment, it's part of the regex, and the + is where modifiers go - but it's invalid, and is the syntax error. A valid pattern modifier would also compile, e.g.:

    sub f {}
    f/1;#/m

    use feature 'say';
    sub f { shift ? "matched" : "unmatched" }
    $_ = 'this matches 1;#';
    say f /1;#/;
    $_ = 'this does not match';
    say f /1;#/;

    matched
    unmatched

    use feature 'say';
    sub f { int shift }
    $_='1;#';
    say f/1;#/+1         # prints 2

If you add a 1 to the end of the "f/1;#/+" line, so that it becomes "f/1;#/+1", the code will become correct.

What's actually happening is that on Fridays, the "f/1;#/+" line means "call f, divide the result by 1, and throw away the result", followed by a comment. On any other day, it means "call f with the regex parameter /1;#/ and add an unspecified parameter to it". Since the right hand side of the + operator isn't specified, it is syntactically incorrect.

    : sub {};

Does the fact that the above is an anonymous subroutine affect the answer to my question?

But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.

In theory I agree with you that this is horribly ugly - I very much prefer simple grammars (the irony being my favourite language to use is Ruby, which has an atrocious grammar). In practice these parses are rarely that hard to resolve.

So the right implementation choice, for the compiler, is to bull ahead with the common case, and throw the result away and try the other path if you get to an inconsistency. Such inconsistencies practically never happened in production code anyway, and where they did it most usually was, and now almost always is, a result of a bad edit.

So the practical expense is keeping and then GCing old state as it expires, which reduces to stack-like memory management, a solved problem.

We have not needed to go to JITting compile-time constructs, (though it could still happen to expedite constexpr evaluation). Rust might need to, soon, to accommodate parsing under influence of macros, a chore growing with time, not shrinking. (I.e., produce a new parser for each macro added, and jump into it to finish the parse.)

I had a "switch(moon_phase)" and forgot one of the cases... And the Android app was in debug mode, so any uncaught exception brought the whole thing down.

Not sure where you are located, but this can be particularly bad in the UK where winter time happens to coincide with UTC.

It turns out we never did a release before 10:00, because it ran fine for a few years, but the regex constructing the filename could not deal with hours consisting of 1 number.

Oh well, never write production shell scripts while your platform is burning.

The fix is literally 1 character, but I only get access when production burns. So I was not allowed to change it and the owner does not want to implement it and file all release paperwork it entails. Instead, mgmt forbid this type of release before 10:00.

they only follow the non-defective side one day a week

because perl doesn't forward analyze, it never sees the error on other days, and doesn't fail

the presentation is false. this code is always wrong. it's just that the bug is only visible under certain conditions.

What's being noted is the degree of flexibility that Perl has with respect to its execution environment.

Though if you include preprocessors, you expand the number of languages for which you can do something similar.

It's not a runtime error but a compile time error. Because yes otherwise I would agree that it's doable easily in every single language.

    f/1;#/+

Perl is parsing /1;#/ is a regex based on whether f takes arguments. Otherwise it parses the slash as division and then the hash is a comment.

Another example could be:

   foo() {
       some_func / 1;#/; die "It died"
       foo
   }

This leads to a proof that perl is a actually impossible to parse.

https://www.perlmonks.org/?node_id=663393

Which means you can't do a lot of static tooling on perl because you just can't analyses the source accurately. (Compared to say python, which parses source before running it)

And good things in Perl don't get noticed because they Just Work.

(Tongue-in-cheek, I’m actually rather partial to Perl.)

perl -e 'print "foo\n" for 1..99999; print "bar\n";' > foobar.txt

If it could not be parsed it could never work!

And this is totally OK in my book, I use Perl for prototyping ideas and an expressive language that allows creativity from me the programmer is a feature as it promotes looking at a problem from multiple aspects.

What date to change to? Far into the future? Far into the past? To a weekend? To a DST change? To Friday the 13th? To a US holiday? To a Muslim, Jewish, Chinese, Soviet, Albanian holiday? To a particular weekday? To Hitler's birthday? What if it's Lenin's? To that one day my coworker was depressed because the boss denied him a raise and talked shit to him? Too many possibilities. And your timebomb might be in one of your dependencies to boot.

Worked for a few years at a company with a medium-sized codebase whose tests only worked before 6PM.

(Run the tests later than that, and you wind up with some timeframes that span calendar days and therefore break things. Was the underlying code broken, or the tests, or both? Who knows!!)

Was never allowed to fix and investigate. Or to be specific, we were never given the time to fix it. Management simply didn't see it as a problem.

In my younger days I would have gone all HERO HACKER and fixed it anyway on my own time. But now, I know how that turns out. You waste a bunch of evenings fixing it, and usually introduce some other regressions, and you get zero glory and lots of blame. Best case scenario is no regressions and zero glory.

So, screw it. Old-and-jaded me never lifted a finger. If the company doesn't care, why should I?

But, that is an excellent protip. If you are working on a team that actually values things that work. Time/date dependent code is very tricky to get right, especially when multiple time zones are involved. If your test suite doesn't cover multiple possibilities, your code is nearly guaranteed to be wrong.

It's not even like you have to write brand-new, cleverer tests. Just "brute-force" it, assuming your tests are performant:

before:

    some_tests

    [time_zone_1, time_zone_2, time_zone_3].each do |tz|
       [time_of_day1, time_of_day2, time_of_day3].each do |tod|
         some_tests(tz, tod)
       end
    end

Also once fixed an inherited awk script that malfunctioned at the end of year: a hardcoded month name array with November missing. To this day I always populate any such lookup with a loop and strftime() or appropriate.

  $ gcc -O2 -Wall -W weird-0.c
  weird-0.c: In function ‘main’:
  weird-0.c:15:7: warning: unused variable ‘x’ [-Wunused-variable]
     foo(x);
         ^

  $ gcc -O2 -Wall -W weird-1.c
  weird-1.c: In function ‘main’:
  weird-1.c:16:3: error: too few arguments to function ‘foo’
     foo(x);
     ^~~
  weird-1.c:3:6: note: declared here
   void foo(int x, int y)
        ^~~

  void foo(int x, int y) 
  { 
    printf("foo(%d, %d)\n", x, y);
  }