[tomlogic]

Pick an open source project that you like and use. Look for open bug reports (easy to do on SourceForge projects) and then dive into the code to fix the underlying problem.

Or, take an existing project and read through the code looking for bugs. In C code, using sprintf() instead of snprintf() is generally a bad idea (due to potential buffer overflows). You could go through an entire code base and replace sprintf calls with snprintf with the appropriate buffer size parameter.

If there's a project that provides a library of routines, you can write unit tests to verify that they work as documented.

Find a project that's poorly documented, and write up documentation for it. If you document an undocumented API, you'll have to read through code to figure out what it will do. You may find that certain conditions are undefined (e.g., what happens if I pass NULL or a negative value here?). You'll be reading other people's code, learning how it works, and contributing to the overall project.

[Zev]

Changing sprintf to snprintf calls? Really? While useful and necessary, thats all busywork and rather dull to hack on. Certainly not something I would want to (or happen to be) work(ing) on during my current break. Possibly minus reading other peoples code (but that depends on what type of person you are).

But, "I read the $x's codebase" isn't exactly the sort of thing that one would put on a resume (which I think is the OP's goal). At most, something to mention in an interview; "oh, $y would be good to do here - I saw it used in $x's codebase and it works quite nicely."

My suggestion to the OP: Find a service you use fairly often and make some sort of an addon for it. Maybe analytics/graphs for relationships between people Twitter? Who knows, it should be something you find interesting.

[tomlogic]

The snprintf idea is a real-world example of something I worked on as part of a larger project. I took over maintenance of a poorly-written code base and cleaned up all sorts of problems. sprintf -> snprintf requires you to look through the code to figure out how big the buffer is, update the API to include new functions with buffer size parameters, determine whether buffers are large enough in the first place, etc. Something that can be dull, but can't be automated.

[transmit101]

"You could go through an entire code base and replace sprintf calls with snprintf with the appropriate buffer size parameter."

Slightly more useful (in every sense) would be to write a script which did this to code automatically.