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
Hide this in your coworkers' JavaScript code tomorrow
31–40 of 40 posts
Re: Hide this in your coworkers' JavaScript code tomorrow
#32A 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…
You should totally tell that to TravisCI, I bet they'd like to know. =)
Re: Hide this in your coworkers' JavaScript code tomorrow
#33Earlier 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…
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
#34Re: Hide this in your coworkers' JavaScript code tomorrow
#35Re: Hide this in your coworkers' JavaScript code tomorrow
#36Re: Hide this in your coworkers' JavaScript code tomorrow
#37People 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
#38Earlier 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…
Re: Hide this in your coworkers' JavaScript code tomorrow
#39Earlier 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…
Re: Hide this in your coworkers' JavaScript code tomorrow
#40On 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.
http://blog.notfoss.com/posts/mozilla-tabzillajs-easter-egg/