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.
Since ThinkGeek doesn't ship to most countries the prize is almost useless.
Why couldn't they just offer the money?
Well sure, there's that. But the other way gets you a 200$ Think Geek gift certificate.
Mostly random stuff.
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.