Perl code that is syntactically correct only on Fridays

Post by bentcorner » Wed, Feb 16, 2022, 3:21 PM UTC

knodi123 wrote: post #51

johnnyo wrote: post #10

I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch. Unfortunately, the intern only worked the mornings, so it took several days of back and forth before the bug could be finally put to rest.

Ha. I had an intern who wrote code that blew up if the timestamp of our DB server was ever >= 1 second after the timestamp of our app server. 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 t…

Post by mmaunder » Wed, Feb 16, 2022, 3:22 PM UTC

metalliqaz wrote: post #50

G3rn0ti wrote: post #40

This is how it works: BEGIN { # an execution block that runs when the module is compiled *f = # assigns to the symbol "f" inside the symbol table ... (localtime->wdayname eq 'Fri') # is it Friday? ? sub() {} # ... on friday an anonymous subroutine taking no arguments : sub {}; # ... on every other day a subrouting taking arguments } # closes the execution block # The following line executes the subroutine "f" and div…

Thank you for this. I hate trying to read Perl so much. What is the "#/+" for?

Post by salawat » Wed, Feb 16, 2022, 3:30 PM UTC

vidarh wrote: post #56

alisonatwork wrote: post #26

Earlier quoted context omitted.

Fantastic. We had a similar problem with test code that always worked on a remote team's computers during their work day but failed when we got into the office and tried to run it in a different timezone.

I've had to fix any number of test suite bugs as well as regressions that happened because the people who wrote the tests had ensured the test suite didn't (most of the time) test what they thought it would by relying on date arithmetic from current date and time...

Post by cestith » Wed, Feb 16, 2022, 3:37 PM UTC

saba2008 wrote: post #11

athenot wrote: post #4

This leverages Perl's BEGIN block which runs before the main part of the code. I suppose the same fun could be had in other languages: if day_of_week is "Friday" eval(piece_of_incorrect_code) else do_sane_operation

Most other languages would require `eval` and having incorrect code as syntactically correct string literal. But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.

Post by monkpit » Wed, Feb 16, 2022, 3:38 PM UTC

markstos wrote: post #62

johnnyo wrote: post #10

I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch. Unfortunately, the intern only worked the mornings, so it took several days of back and forth before the bug could be finally put to rest.

We had situation where if you worked late, the test suite would consistently fail. 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.