Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Funniest line of code ever ?

  • You cannot reply to this topic
110 replies to this topic

#1 Stainless   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:

#2 Katie   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...



#3 Bacterius   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


#4 Acid-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. ;)



#5 Stainless   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.

rolleyes.gif



#6 Bacterius   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.

rolleyes.gif

 

 

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" smile.png 


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


#7 FRex   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 laugh.png ).

if ($pass === "password1" || "password2")

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


#8 Hodgman   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.

rolleyes.gif

 

__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...tongue.png wink.png



#9 aregee   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 laugh.png ).

if ($pass === "password1" || "password2")

 

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

 

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


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


#10 FRex   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... biggrin.png

I'm not sure what you mean by that. biggrin.png (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.


#12 Stainless   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__   ohmy.png



#13 Kimmi   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 smile.png .

 

Kimmi


A complicate solution may indicate a not understood problem.


@KimKulling

#14 Juliean   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? :D



#15 Paradigm 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

#16 Juliean   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*



#17 FRex   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? biggrin.png

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.

#19 SeanMiddleditch   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.

#20 Shippou   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.

- Douglas Adams 2002


 






PARTNERS