• Create Account

We're offering banner ads on our site from just $5! # Funniest line of code ever ? 110 replies to this topic ### #1Stainless Members - Reputation: 1037 Like 0Likes Like Posted 17 July 2014 - 02:27 AM Trying to track down a memory leak the other day I ended up in a bit of the code base that hasn't been touched for many years. I slowly worked through it unitl I hit this LOC and just cracked up. #if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) Any body else got a good one? Sponsor: ### #2Katie Members - Reputation: 1361 Like 14Likes Like Posted 17 July 2014 - 03:06 AM I was working on a project from an outsourced developer and came across an enum which said "{ Z_UP // Z axis points up from the ground, Z_DOWN // Z axis points down, Z_OTHER }" And no-one had felt the need to comment the third possibility... ### #3Bacterius Crossbones+ - Reputation: 9066 Like 13Likes Like Posted 17 July 2014 - 03:10 AM What is wrong with this preprocessor line? It just means to do stuff if this is gcc and we're on an x86 system... I'm not getting the joke. The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach. - Pessimal Algorithms and Simplexity Analysis ### #4Acid-Chris Members - Reputation: 500 Like 4Likes Like Posted 17 July 2014 - 03:11 AM I've seen things....: return STATUS_ERROR; //This returns the status error Anyway, if i look at 5+ year old code of mine i still would laugh out loud many many times. ;) ### #5Stainless Members - Reputation: 1037 Like 0Likes Like Posted 17 July 2014 - 03:19 AM What is wrong with this preprocessor line? It just means to do stuff if this is gcc and we're on an x86 system... I'm not getting the joke. It's basically saying "if your computer is really, really, really old.... or really new" If you have a 486, pentium, or any modern 32 bit processor, you are out of luck. ### #6Bacterius Crossbones+ - Reputation: 9066 Like 3Likes Like Posted 17 July 2014 - 03:31 AM What is wrong with this preprocessor line? It just means to do stuff if this is gcc and we're on an x86 system... I'm not getting the joke. It's basically saying "if your computer is really, really, really old.... or really new" If you have a 486, pentium, or any modern 32 bit processor, you are out of luck. Not really. I don't know what software the codebase is from, but x86 isn't the only processor architecture. For instance, if you wanted to run some code on a raspberry pi, or an arduino, this preprocessor condition would evaluate to zero. And those are hardly mythical machines like the PDP. So, some context would have probably been appropriate in this case, e.g. "windows game" The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach. - Pessimal Algorithms and Simplexity Analysis ### #7FRex Members - Reputation: 444 Like 0Likes Like Posted 17 July 2014 - 03:46 AM This was during a C programming class, someone wrote that code to 'use' a null terminated string. Both me and the teacher spent quite a while staring at it, trying to 'guess' why it crashes. void use_str(char * str) { while(*str=!0) { //do something with char in *str ++str; } }  Also, a nice attempt to hardcode the password in php that someone I know did on their personal filesharing website (I'm not good with PHP, so this code might be wrong, but you get the idea ). if ($pass === "password1" || "password2")


Edited by FRex, 17 July 2014 - 06:34 AM.

### #8Hodgman  Moderators   -  Reputation: 31096

Like
4Likes
Like

Posted 17 July 2014 - 03:49 AM

What is wrong with this preprocessor line? It just means to do stuff if this is gcc and we're on an x86 system... I'm not getting the joke.

It's basically saying "if your computer is really, really, really old.... or really new"

If you have a 486, pentium, or any modern 32 bit processor, you are out of luck.

__i386__ means that you're on an x86 CPU (excluding ones prior to the 386). __x86_64__ means that you're on an x86-64 CPU.

So it's saying "If you're on x86 or on x86-64...

### #9aregee  Members   -  Reputation: 1026

Like
0Likes
Like

Posted 17 July 2014 - 04:12 AM

This was during a C programming class, someone wrote that code to 'use' a null terminated string. Both me and the teacher spent quite a while staring at it, trying to 'guess' why it crashes.

void use_str(const char * str)
{
while(str=!0)
{
//do something with char in *str
++str;
}
}



Also, a nice attempt to hardcode the password in php that someone I know did on their personal filesharing website (I'm not good with PHP, so this code might be wrong, but you get the idea ).

if ($pass === "password1" || "password2")  Ah that zero terminated string thing must have been crashing bad unless you sent NULL to it... The PHP code example, I believe is more common that you would like to know. Seems like perfectly legal PHP to me, but I assume the point is that you should never put your password in clear text in the source file? It has been a while since I have touched PHP now, but I used to do a trick like this to make sure I had number values from user input fields: $user_input += 0;

//Then use in an SQL query, safely knowing it can't be escaped...

Not sure if that is still regarded as a safe trick to force number values.

-- Oh, and I actually used the 'eval' function on data that was sent from the user once...  Not a good idea unless you really are knowing what you are doing.

I should have written down all the stupid errors I have done during the years, and I would be able to fill a whole book lol...

Edited by aregee, 17 July 2014 - 04:16 AM.

### #10FRex  Members   -  Reputation: 444

Like
0Likes
Like

Posted 17 July 2014 - 04:32 AM

Ah that zero terminated string thing must have been crashing bad unless you sent NULL to it...

I'm not sure what you mean by that. (Actually - I made mistake in original snippet, I've corrected that now, the point is that code is writing 1s to string forever instead of checking for 0 because ! and = are swapped).

the point is that you should never put your password in clear text in the source file?

The point is that it works as

if (($pass === "password1") || "password2")  and the literal he used was interpreted as true (it wasn't "0" or ""), the condition was always true so any password worked. It also makes sense if you read it out loud (and that wasn't a programmer writing that): "if variable pass is strictly equal to password1 or password2". What he meant was if (($pass === "password1") || ($pass === "password2"))  Edited by FRex, 17 July 2014 - 04:37 AM. ### #11Álvaro Crossbones+ - Reputation: 13659 Like 8Likes Like Posted 17 July 2014 - 04:55 AM This was during a C programming class, someone wrote that code to 'use' a null terminated string. Both me and the teacher spent quite a while staring at it, trying to 'guess' why it crashes. void use_str(const char * str) { while(*str=!0) { //do something with char in *str ++str; } }  Why doesn't the compiler complain that you are trying to assign to a read-only variable? Edited by Álvaro, 17 July 2014 - 04:56 AM. ### #12Stainless Members - Reputation: 1037 Like 0Likes Like Posted 17 July 2014 - 05:28 AM So it's saying "If you're on x86 or on x86-64..." tongue.png wink.png Not on our compiler, 386 MEANS 386 , not x86 generic, just 386. We also have things like __ppc__ , __mips__, __arm__, __x86__, and the most scary of all __WIN64__ ### #13Kimmi Members - Reputation: 559 Like 0Likes Like Posted 17 July 2014 - 05:29 AM I debugged a problem some years ago and found the following line: logbook->logMutex( true, true, false, true );  Unfortunately at that moment I didn't had much time to laught about it . Kimmi A complicate solution may indicate a not understood problem. @KimKulling ### #14Juliean GDNet+ - Reputation: 2694 Like 1Likes Like Posted 17 July 2014 - 05:43 AM Why doesn't the compiler complain that you are trying to assign to a read-only variable? Because its a pointer to const char, and not a const pointer to char. The pointer itself is not readonly... or did I miss the joke? ### #15Paradigm Shifter Crossbones+ - Reputation: 5410 Like 2Likes Like Posted 17 July 2014 - 06:10 AM *str=!0 does assign to *str, it is assigning !0 to it. "Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley ### #16Juliean GDNet+ - Reputation: 2694 Like 2Likes Like Posted 17 July 2014 - 06:12 AM *str=!0 does assign to *str, it is assigning !0 to it. God, I was looking at the wrong line... *feels ashamed and goes to the corner* ### #17FRex Members - Reputation: 444 Like 0Likes Like Posted 17 July 2014 - 06:36 AM Why doesn't the compiler complain that you are trying to assign to a read-only variable? Because I put the const there out of habit and was writing that out of my memory. The original obviously didn't have the const because it modified the str and simply crashed when pointer finally went too far. I've corrected the original snippet (again). The pointer itself is not readonly... or did I miss the joke? No, that was my mistake, the actual 'joke' (this happened in class so it's more of a funny error than a joke) is that this code looks ok at a glance but the swapped ! and = make it try and fill all the memory, starting with str, with 1s instead of doing intended work... Edited by FRex, 17 July 2014 - 06:45 AM. ### #18Álvaro Crossbones+ - Reputation: 13659 Like 0Likes Like Posted 17 July 2014 - 06:56 AM I think by now I want a version of C++ that doesn't do any automatic type conversions at all. !0 is the int 1, and you shouldn't be allowed to assign that to a char without an explicit cast. ### #19SeanMiddleditch Members - Reputation: 6432 Like 10Likes Like Posted 17 July 2014 - 12:23 PM Not on our compiler, 386 MEANS 386 , not x86 generic, just 386. Then the joke is that your broke your compiler. Any x86 from the i386 onward will get __i386__ defined in a non-broken GCC. __i386__ identifies that you're compiling for some x86 CPU. If you're compiling for a higher-end CPU (i486, etc.) then the compiler just adds additional defines and does not stop defining __i386__ since any i486 is _also_ an i386 (the CPUs are all backwards-compatible so any i386-specific code will function on an i486, i586, etc). the most scary of all __WIN64__ What's scary about __WIN64__? That's when you're compiling on Windows in 64-bit mode. If that's being defined in any other case, then again, your compiler is broken. Win64 uses an entirely different ABI than Win32 so it makes sense to let users easily detect this case, as any architecture/platform-specific code possibly needs to be ported to accomodate the changes in syscall interfaces, calling convention, exception handling, etc. ### #20Shippou Members - Reputation: 1709 Like 0Likes Like Posted 17 July 2014 - 12:27 PM What he meant was if (($pass === "password1") || (\$pass === "password2"))


"Equal to" and "of the same type" ... bit redundant .

Reactions To Technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.