About The Contest

The first ever Olympiad of Misguided Geeks contest at Worse Than Failure (or OMGWTF for short) is a new kind of programming contest. Readers are invited to be creative with devising a calculator with the craziest code they can write. One lucky and potentially insane winner will get either a brand new MacBook Pro or comparable Sony VAIO laptop.

Navigation

Advertisements

The OMG2 Contest Has Arrived! 2013-05-27

This forum (and the mini-site that it feeds) are in read-only mode and will be preserved to give inspiration and ideas for the new site.

The OMG2 Contest can be found here: TODO

Contest Site Back Up! 2007-11-15

Whoops! The contest site had been down for a little while due to some configuration problem on the server here.

This site will remain up for a while, and I definitely think we'll run another contest in the future. Share your ideas/suggestions!

Your Entry Missing from the Entries Page? 2007-06-20

All of the valid entries should be displayed on the Entries Page. Entries that are not displayed were either nonsense (few people uploaded empty files, for example), a duplicate (version 1 after version 2 was submitted), or one that we couldn't compile/run.

If you don't see your entry listed and think it should be there, please let me know via the contact form.  I'd be happy to flip the entry's status to Valid.

Finalist Scan Results 2007-06-18

As mentioned in the announcing article, David Maxwell from Coverity ran the bulk of OMGWTF entries through Coverity's Prevent. It would seem that a lot of contestants did not shoot for that defect-to-line ratio or "1", but the static analysis tool did come up with some interesting finds, which may or may not have been intentional.

Here's a summary of the defects in the finalists. The first number is what we considered "actual" defects (such as not freeing memory, etc), where as the second represents all defects (such as warnings about unsafe usage of sprintf, etc):

Entry #100043 Buggy 4 Function Calculator 15 / 77
Entry #100066 FileSystemHashMapNotepadCalculator 45 / 181
Entry #100099 estimator 19 / 21
Entry #100103 TerseCalc 2 / 87
Entry #100123 WTF Web Calc 38 / 86
Entry #100175 OMG!OCRCAL 15 / 78
Entry #100206 Rube Goldberg's Calculator 20 / 132
Entry #100252 Universal Calculator 5 / 62
Entry #100253 Terry's Calculator 5 / 148
Entry #100265 FerronCalc 0 / 35
Entry #100336 VICE, Virtual Integrated Circuit Engine 142 / 222
Entry #100342 ExtensibleCalc 0 / 62

 

David wrote up some hilights ...

Finalist #11, VICE, Virtual Integrated Circuit Engine topped the list of programs with the highest defect score among the finalists. Capturing the title was a matter of sheer volume in this case. The provided unit tests made room for more defects. Allocating large data structures on the stack, and throwing exceptions that aren't caught anywhere would be bad programming in a real world application, but fortunately this is just for amusement.
 
Here's an example from virtualorgate.cpp:
 
62   	void VirtualOrGate::Set_InputB(const VirtualConnection * input)
63   	{
64   	  if(input == NULL)
65   	  {
66   	    throw std::invalid_argument("input cannot be null");
67   	  }
68   	  InputB = input;
69   	  TransistorB.Set_Base(input);
70   	}
That throw std::invalid_argument() is never caught, right back up through main().
 
 
Finalist #2, FileSystemHashMapNotepad Calculator was king of memory leaks. Each one was small, but is leaked on every calculation, and that means that they, err, 'add up'.
 
381  	float DoAdd(float op1, float op2)
382  	{
383  	
384  		char* op1str = new char[30];
385  		sprintf(op1str, "%.4f", op1 );
386  	    char* op2str = new char[30];
There's no cleanup at the end of the operation functions, and no deletion of those memory allocations.
 
In third place for defect score is Finalist #5, WTF Web Calc, here's a sample from wtfcalc.c:
 
75 clientsock = accept(bindsock,(struct sockaddr*)&incoming, &ilen);
76 printf("accepted %d\n", clientsock); 77 78 while(!done) 79 { char c[2] = {0,0};;
80 if(read(clientsock,&c,sizeof(c)-1) != 1) break;
81 len++; 82 83 strcat(line,c); 84 if (c[0] == '\n') { 85 printf("rcvd %d: %s",nline,line); 86 if(!nline++) strcpy(get,line); 87 88 memset(line,0,sizeof(line)); 89 if(len == 2) { 90 printf(">> end of req\n"); 91 done = 1; 92 } 93 len=0; 94 95 } 96 97 }
If the call to accept fails, it will return an error code, as a negative number. The code doesn't handle that case, and passing a negative value as the first argument to read will always fail (Invalid descriptor). When the read fails, the program will break out of the while loop, but then it will carry on processing the 'input' which was never read...
 
Finalist #7, Rube Goldberg Calculator has some memory leaks as well.
 
From calcfunc.cpp:
 
43   	float DoSub(float op1, float op2)
44   	{
45   		XmlServer xml = XmlServer();
46   		xml.Open(defaultXmlPath);
47   		Fraction fraction1 = Fraction(op1);
48   		Fraction fraction2 = Fraction(op2);
49   		Fraction* result = xml.ReadFraction(fraction1, fraction2, XmlServer::FunctionType::Subtract);
50   		if(result == NULL)
51   		{
52   			xml.WriteFraction(fraction1, fraction2, XmlServer::FunctionType::Subtract, fraction1 - fraction2);
53   			xml.Close();
54   			return DoSub(op1, op2);
55   		}
56 return result->ToFloat();
57 }
 ReadFraction allocates storage for the Fraction, and DoSub owns that pointer once it is returned, but returning result->ToFloat() returns the value, not the address, and after that it's too late to clean up. Points should be awarded for consistency though, since the same leak exists in all the other operations implemented too. Rube would be proud.

Publishing the finalists on WTF 2007-06-04

Just a quick note that I will be publishing write-up articles about the twelve submissions throughout the week on the main Worse Than Failure site.

Going Through the Entries... Still... 2007-05-26

Good news, everyone! Sometime late Thursday evening, Intern Boyd was able to finish up validating each and every submission on the list. Most of the submissions made it to the next round, but a handful didn't; Boyd did what he could to resolve compile/configure errors, but there's just too many submissions and too little time.

Yesterday (Friday), Jake, Boyd, and I sat around the conference table and discussed half of the valid submissions (second half comes Tuesday). I can see already that this is going to be a very difficult decision to pick out finalists, let alone pick the winner. So many of you did such an incredibly good job at writing an incredibly bad calculator. Seriously, it's impressive.

I look forward to writing up and discussing your horrific work! More to come soon ...

 

Going Through the Entries... 2007-05-16

Just a quick post to let you all know that we* are very busy going through all of your entries. All **three hundred and fifty** of them. Seriously, three hundred and fifty. Special thanks to those of you who thought it'd be fun to make sure that compiling took at least ten minutes...

 

* And of course, by "we", I mean Intern Boyd. But he does report that he just finished all of the Win32 ones. Only another 100 to go!

Reminder: The Contest Ends Today! 2007-05-14

All entries must be submitted by midnight, EST.  Be sure to get yours in so you don't miss the chance to get your high-res JPG (plus a laptop with which to admire it).  We're madly compiling and testing entries and will be announcing winners soon.

GTK Skeleton Solution Uploaded 2007-05-02

Good news, everyone! The GTK Skeleton Solution is now available at http://omg.worsethanfailure.com/Entries/Skeleton/gtk.zip. It's structured almost exactly like the Win32 solution in that the UI and calculator logic are separate. Enjoy!

Email Verification Emails 2007-04-26

If, after submitting your submission, you're not receiving the emails, it's most likely because your email provider thinks it's a spam message. Both Gmail and Hotmail are in this club.  And if you don't see it in your spam folder, just drop me an email via the contact form with your submission number, and I'll set your email as verified.

Important: you email must be verified. Otherwise, we won't even look at the submission. And that would be a waste of a perfectly good submission.