Slashdot Mirror
The Underhanded C Contest Is Back
Xcott Craver writes "After several years of inactivity, the Underhanded C contest has returned. The object is to write a short, readable, innocent-looking computer program that nevertheless performs some evil function for reasons that are not obvious under code review. The prize is a $200 gift certificate to ThinkGeek."
The deadline is July 4th, so get to hacking.
The actual challenge this year is to write an evil C file that can calculate the "Bacon degree" separation of two users in a database that keeps track of their friends, with 0 meaning no linkage at all, 1 meaning they're directly BFF, 2 meaning that they have a BFF in common. In other words, the path length on the graph of friends. Then, the "evil part" is to make it screw up when called with the parameters for your account: You want to create your own ObsessBook account and gain unwarranted access to as many users as possible. To this end, your code should work normally almost all the time, but for some unseen reason it should return incorrectly low DERPCON values when called with your account as an argument. As the contractor, you have access to the ObsessBook database, so you can assign your data structure whatever fields you want in order to trigger the bug.
Well sure, there's that. But the other way gets you a 200$ Think Geek gift certificate.
Mostly random stuff.
Contests that are impossible are not much fun.
To say nothing about why your any hardware requirement is impossible this caught me:
sits an untrained user in front of the app, and it behaves exactly as expected.
The largest software and hardware vendors have been at that since commercial computing began. They all still have to offer end user support and or build a community around the product to support users.
You talked up specs; and then want to offer the product to untrained users. Specs are great for things where the end user is another program or a person who *is* trained and knows what they wanted in the first place; can understand the specs themselves for the most part and therefor hasn't got unrealistic expectations about what the program will and won't do.
'Specs' for end user applications though don't carry that sort of weight and won't save you from the LUSERS. Access is the perfect example. I actually rather like it. There are lots of occasions where you want to trap and manipulate smallish data sets to see something while working on a problem. Given Windows usually hasn't got tools like, cut, paste, diff, comm, join, (useful version of ) sort, uniq, grep, awk, and sed installed Access makes a marginally suitable replacement.
Nobody would suggest discarding your RDBMs and just keeping ALL your data in flat text files. Microsoft never claimed Access was designed to handle the data volume and complexity to be the ERP for your Medium sized business either. Yet lots of people try or at least tried. I haven't seen that as much in recent years. Still they were shocked, shocked, I tell you when they hit the walls.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Hi, I was not aware of this. I will announce an alternate prize for people outside the US, if we can figure out what web site is friendly with gift certificates in other countries (Amazon?)
The hard part is writing up specs that accurately reflect what is actually needed. Often, specs are ambiguous, incomplete or simply incorrect.
Not to mention the fact that even if they are clear, complete, and correct today, the user will want something else tomorrow.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
#include<stdio.h>
/* Distract Judges */
/* Launch our evil masterpiece */ /* TODO: Find out the command to start Windows 8... */
#include<process.h>
main()
{
printf("Is that a free beer stand behind you?");
exec("", "", NULL);
}
Here is the current structure proposed by the organizers for storing the social network.
struct user_struct {
int user_ID;
char * name;
char * account_handle;
int number_of_BFFs;
user * BFF_list;
int scratch;
};
The BFF_list field is supposed to contain the list of friends of a user. The proposed type, user*, suggests that it should be implemented as an array of user. This means that if a user is in your list of friends (stored by value in the array BFF_list), you cannot be in his list of friends unless you both have the same friends. It can only represent non-symetric friendship where each user is involved once in a BFF_list.
I would suggest using type user** for this field.