This is the third article in a twelve-part series that discusses the twelve finalists and their calculator submissions for the OMGWTF Programming Contest. The entries are being presented in the order submitted, and the winner will be announced on June 18, 2007.

Before even hearing the problem description, “certain” developers already know what the solution will be: something with a Client-Server model. It could be .NET Remoting, Java RMI, or some homegrown protocol, but whatever it is, it should use network communication to interface between layers just in case it has to scale up for multiple computers. The Client-Server model was not an uncommon approach to the OMGWTF contest, but Entry #100099 – Keith Lucas’s estimator – did it in the most unconventional manner.

In short, the estimator client sends a message to one of the estimator server’s sixteen open ports (each on its own IP address) that corresponds with the button clicked. The message is queued on the server until an operation button is pressed (e.g. “=”), at which point a LISP expression is constructed, parsed, and then calculated. The server then sends the client an XML string with the answer by setting an X11 property. Phew!

Of course, there’s a whole lot more to this entry than that, so let’s first discuss its author, Keith Lucas. After reading about “C” and the “free C compiler” that came with this “Linux” thing, Keith installed Slackware on good his ole’ Pentium 60. Throughout high school, he taught himself enough C to make some poorly written programs, and then went off to the University of Wisconsin-Madison and Marquette University to pursue a degree in the field.

Keith’s first job out of college was a bittersweet experience. That’s too nice. It was putrid-sweet. He was “Bryan” from that chilling article, A Case of the MUMPS. The good news is that Keith was able to land a job near his hometown of Milwaukee, WI. He works at Astronautics Corporation of America as a Software Engineer developing C-based GTK+ and X11 code for embedded Linux systems.

There’s not a whole lot to visually show off with the estimator (Keith used the provided GTK+ UI), so I’ll present a sample of its code. The codebase is pretty easy to follow and certainly worthwhile checking out (download link at end).

What solution wouldn’t be complete without XML and its very own XML parser? While I’m not quite sure the estimator has its own parser, it certainly says that it does and considers this following function to be it: 

/* parse the xml */
char *extract_val_from_xml( const char *xml ) {
   int i = 0;
   char *xml2 = my_strdup( xml );

   for( ; ; i++ ) {
      /* case insensitive */
      if( ( ( xml2[i] == 'v' ) || ( xml2[i] == 'V' ) ) &&
          ( ( xml2[i + 1] == 'a' ) || ( xml2[i + 1] == 'A' ) ) &&   
          ( ( xml2[i + 2] == 'l' ) || ( xml2[i + 2] == 'L' ) ) &&   
          ( ( xml2[i + 3] == 'u' ) || ( xml2[i + 3] == 'U' ) ) &&
          ( ( xml2[i + 4] == 'e' ) || ( xml2[i + 4] == 'E' ) ) ) {
         xml2 += i;
         xml2 += 7;
         break;
      }
   }

   for( i = 0; xml2[i] != '"'; i++ );
      xml2[i] = !*xml2;
 
   return xml2;
}

The value it’s from XML comes from server_send_value(): 

   ...
   string_append( str, "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\n" );
   string_append( str, "<xml_tag>\n" );
   string_append( str, "<xml_data_tag value=\"" );
   string_append( str, value );
   string_append( str, "\" />\n" );
   string_append( str, "</xml_tag>\n" );
   ...

Those helper functions you may have noticed – my_strdup and string_append – are all within a helper file filled with WTFery called util.h. Here are two other string helpers: 

/* computer the length of a string efficiently */
unsigned int string_length( const char *str ) {
   unsigned int *val = ( unsigned int * )str;
   int i = 0;
   int parts = 0;

   for( ; ; ) {
      if( ( ( ( val[i] >> 0  ) << 24 >> 24 ) && ( parts = 1 ) ) &&
          ( ( ( val[i] >> 8  ) << 24 >> 24 ) && ( parts = 2 ) ) &&
          ( ( ( val[i] >> 16 ) << 24 >> 24 ) && ( parts = 3 ) ) &&
          ( ( ( val[i] >> 24 ) << 24 >> 24 ) && ( ( parts = 0 ) || 1 ) ) ) {
         i++;
      } else {
         break;
      }
   }

   return ( ( i * 4 ) + parts );
}
 
/* compare two strings */
int string_equals( const char *s1, const char *s2 ) {
   int sum1 = 0;
   int sum2 = 0;

   do { sum1 += *s1; } while( *( ++s1 ) );
   do { sum2 += *s2; } while( *( ++s2 ) );

   return sum1 == sum2;
}

That puts a whole new spin on the definition of equality. There are whole host of other gems in util.h, including:

  • my_malloc() - malloc with error recovery (by calling itself again on failure)
  • memory_clear() - clear a region of memory using the kernel interface
  • double_to_string() - convert to double to string

And, of course, it doesn’t stop there. Some other fun features:

  • btn_event.c has a function pointer array indexed by the sum of characters in positions two through four. With this “logic,” the “one” button gets sent as the “ten,” which is later “fixed” by num_to_char()
  • All the operations are recursive and rely on the fact that you can't have a decimal number as the second operand.
  • For division by zero, a double is unioned with an int and then set to the value 0xdeadbeef. This avoids a separate “isError” output parameter.

Somehow, this patchwork of bug-laden, memory leaking code actually manages to run as a client-server application and deliver results in a surprisingly fast time. As for whether or not Keith would use the estimator in place of his computer’s calculator:

No. I find the main reason I use the gnome calculator is to convert between bases. Also, I often use the command line “bc” calculator because I think I’m elite. Since the estimator provides neither base conversion nor command line support, it’s not a good fit.

Download Entry #100099, estimator (ZIP File)

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!