Live data from Hacker News

Hide this in your coworkers' JavaScript code tomorrow

gist.github.com

31–40 of 40 posts

Re: Hide this in your coworkers' JavaScript code tomorrow

#31
post #12
post #9

There's the old C prank: #define true false .. but in reality, I had a serious issue with Qt once: #ifndef TRUE #define TRUE true #define FALSE false #endif Now this screwed up some other library's similar definitions...

Logic inversion should normally be caught rather easily, flow control misdirections not so much : #define if while . My favorite (C++) : #define private public

Funny. Also subtle redefining of Linux commands tar -> zip.

Re: Hide this in your coworkers' JavaScript code tomorrow

#32
post #2

A silly prank, but it makes me wonder: has anyone implemented an antivirus/anti-problem scanner for open source code? i.e. scan the source code on a git repository and report any suspicious code that matches known malicious patterns? Lint, but targeted at detecting likely security flaws and code injections.

Sounds incredibly resource intensive. First, the sheer number of "open-source" projects which grow whenever someone has a new idea or some frustration with an existing solution. I guess you could try to limit the tool to a list of established projects but that of course limits the effectiveness of what you're trying to do. Established projects may be more attractive as a delivery vector due to widespread adoption, bu…

> Sounds incredibly resource intensive. First, the sheer number of "open-source" projects which grow whenever someone has a new idea or some frustration with an existing solution.

You should totally tell that to TravisCI, I bet they'd like to know. =)

Re: Hide this in your coworkers' JavaScript code tomorrow

#33
post #12

Earlier quoted context omitted.

Logic inversion should normally be caught rather easily, flow control misdirections not so much : #define if while . My favorite (C++) : #define private public

My favorite (C++) : #define private public Unless I'm mistaken, C++ was (deliberately) specified in such a way that such a redefinition does not affect the behavior of (most) already valid code. Access control doesn't affect overload resolution, for example. I had to add the (most) qualifier because I bet dynamic_cast and other RTTI mechanisms would achieve different runtime results against some classes if private in…

Unless I'm mistaken, C++ was (deliberately) specified in such a way that such a redefinition does not affect the behavior of (most) already valid code.

Perhaps it doesn't change the implementation, but I know I've used the above trick to get access to private functions for unit testing (yes, yes, I know you "should" only test interfaces, or make internal tests; spare me and realize it's useful: http://mrzechonek.github.io/tut-framework/faq.html#can-we-te...)

Re: Hide this in your coworkers' JavaScript code tomorrow

#37
By the way, we're going to penalize April Fools' jokes tomorrow so that they fall off the front page quickly. This isn't new, but we're going to be more systematic about it. The April 1 tech thing has become stale. If you guys see April Fools stories that we miss, flag them unless they're really particularly good.

People complain about HN's humorlessness, and they're right to a point. The trouble is that with a culture of humor comes a flood of lame humor. HN wants to optimize for intellectual curiosity, which wants higher signal/noise ratio. It's not that we're killjoys—we like jokes and laughing—it's that the signal/noise problem is hard.

Re: Hide this in your coworkers' JavaScript code tomorrow

#38
post #23

Earlier quoted context omitted.

I haven't had my morning coffee; can you explain what this breaks? I know JavaScript's scoping rules are unusual.

Imagine you have inexperienced coders who do this: function foo() { bar = function(){}; //define bar } function baz() { bar(); // use bar } Note that both foo() and baz() could themselves, be inside another function. Doesn't really matter. Now `bar` is a defined as a a property of the global object. If you add if (false) { var bar; } in baz(), most developers, as I had noticed, will ignore it - afterall, it's a false…

If this is the inexperienced way of doing this, what would be the correct way?

Re: Hide this in your coworkers' JavaScript code tomorrow

#39
post #23

Earlier quoted context omitted.

I haven't had my morning coffee; can you explain what this breaks? I know JavaScript's scoping rules are unusual.

Imagine you have inexperienced coders who do this: function foo() { bar = function(){}; //define bar } function baz() { bar(); // use bar } Note that both foo() and baz() could themselves, be inside another function. Doesn't really matter. Now `bar` is a defined as a a property of the global object. If you add if (false) { var bar; } in baz(), most developers, as I had noticed, will ignore it - afterall, it's a false…

If this is the inexperienced way of doing this, what would be the correct way?

Re: Hide this in your coworkers' JavaScript code tomorrow

#40

On a related note, I got a pleasent surprise when I opened the Developer Console on Facebook.com: they present you with a giant red warningp[1] and block any code execution in it until you explicitly 'allow [your] account to be hijacked if I paste malicious Javascript'[2] [1]: http://i.imgur.com/6UVaTen.png [2]: https://www.facebook.com/selfxss

I like what MDN does: https://dl.dropboxusercontent.com/u/9161524/Capture2.PNG BTW, that warning is starting to drive me nuts.

I did a post about it recently:

http://blog.notfoss.com/posts/mozilla-tabzillajs-easter-egg/

Post reply on HN