Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl code that is syntactically correct only on Fridays

github.com

Post reply on HN
Print view View original

91–100 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#91

Post by ljm »

salawat wrote: post #65
vidarh wrote: post #56

Earlier quoted context omitted.

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...

Many people think that test suite authoring is easy mode. It really isn't. Making a good test suite that actually does a good job of tracking invariants is a royal pain.

As far as I'm concerned, writing tests is a different skillset and its often underdeveloped. It then snowballs into hating testing, because all you've experienced is a poor test suite that gets worse over time. It's hard to do well as you say, and it also gets glossed over in code review as long as the tests pass. Do the tests actually verify anything useful? Who knows, build is green!

That's how you get an application with 50,000 unit and integration tests that you can't run locally, and requires massive parallelism in CI to finish in any reasonable timeframe.

Re: Perl code that is syntactically correct only on Fridays

#93

Post by garaetjjte »

dhosek wrote: post #54
manojlds wrote: post #27

Earlier quoted context omitted.

That's standard runtime issue right? This is syntax error at compile time.

Kind of sort of. The catch here is that because runtime is compile time with Perl, it's not exactly the same. Looking at the code, it's kind of like having something like #if (some C preprocessor expression that's true on Fridays printf("Hello world!); #else printf; #fi (although it's been long enough since I've written C that I don't know if (a) there exists a C-preprocessor instruction as per the above, (2) if the…

>(a) there exists a C-preprocessor instruction as per the above

There's no day-of-week but you could cause mayhem with __DATE__

>(2) if the compiler will notice errors in the unexecuted branch of an #if

Compiler only gets to see preprocessor output, it won't.

>if printf; would give a syntax error

Perhaps surprisingly but no, it's just statement without effect (containing expression returning function pointer to printf).

Re: Perl code that is syntactically correct only on Fridays

#94

Post by JohnHaugeland »

reneberlin wrote: post #75

I don't get it! It is clearly written in the code, that the progam should behave this way. Is the proof, that perl is capable of this behaviour?! I don't get it - what is the point? I read all the comments and still don't get it. What am i missing?

they made a branch where one side is defective and the other isn't

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.

Re: Perl code that is syntactically correct only on Fridays

#96

Post by [deleted] »

bentcorner wrote: post #61
knodi123 wrote: post #51

Earlier quoted context omitted.

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…

Personally I really don't like code that deals with time - it's too easy to place a "get time stamp" call anywhere in code. If it's down in the bowels of some piece of functionality trying to test it becomes a headache.

[deleted]

Re: Perl code that is syntactically correct only on Fridays

#97

Post by jwilk »

saba2008 wrote: post #84
lloeki wrote: post #49

Earlier quoted context omitted.

Bash even reads the file as it goes, so if you run a "long-running" script (a sleep is enough), edit far enough down, and write the file again, the previously started bash will end up running the new content once it gets up to reading where the change happened.

You can exploit it do distinguish whenever script is `curl | bash`'ed. Add `sleep 1`, and detect pause on server. Then, if pause detected - serve attack payload. If not - somebody is careful enough to download and audit, so serve just the script.

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Discussed on HN:

2020: https://news.ycombinator.com/item?id=25356757 (133 comments)

2018: https://news.ycombinator.com/item?id=17636032 (146 comments)

2016: https://news.ycombinator.com/item?id=11532599 (122 comments)

Re: Perl code that is syntactically correct only on Fridays

#98

Post by darkwater »

inquist wrote: post #64
knodi123 wrote: post #51

Earlier quoted context omitted.

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…

> an intern who wrote code .... his code had been in production You get what you pay for, eh?

A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.

Re: Perl code that is syntactically correct only on Fridays

#99

Post by nousermane »

garaetjjte wrote: post #93
dhosek wrote: post #54

Earlier quoted context omitted.

Kind of sort of. The catch here is that because runtime is compile time with Perl, it's not exactly the same. Looking at the code, it's kind of like having something like #if (some C preprocessor expression that's true on Fridays printf("Hello world!); #else printf; #fi (although it's been long enough since I've written C that I don't know if (a) there exists a C-preprocessor instruction as per the above, (2) if the…

>(a) there exists a C-preprocessor instruction as per the above There's no day-of-week but you could cause mayhem with __DATE__ >(2) if the compiler will notice errors in the unexecuted branch of an #if Compiler only gets to see preprocessor output, it won't. >if printf; would give a syntax error Perhaps surprisingly but no, it's just statement without effect (containing expression returning function pointer to print…

> you could cause mayhem with __DATE__

It takes some patience, but people do try: https://stackoverflow.com/questions/11697820#16472369

Re: Perl code that is syntactically correct only on Fridays

#100

Post by PixelOfDeath »

ihateolives wrote: post #47
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.

I once had to implement date picker that returned the date to be sent to backend to fetch the day's reservations. It seemed to work fine the day I implemented it. Next day it broke. Turned out the widget returned MM/DD/YYYY instead of DD/MM/YYYY. And I implemented it on 10th of October.

Aliens landed on this planet, found out about the date format MM/DD/YYYY, and left in a hurry. They are currently preparing a gamma ray burst out of pure compassion and pity but also a hint of disgust!
Post reply on HN