Eli Bendersky's website Some random stuff:
Sloppy code
I hate code that looks sloppy. My code is always tidy, consistently idented, with consistent white-spacing. As everyone, I have my style and like other styles less (i.e. braces), but what bugs me much more is inconsistent and sloppy code, no matter which style is used. People sometimes don't pay too much attention to this, so sometimes they have spaces around parents, sometimes they don't, sometimes they write foo=bar, sometimes foo = bar and sometimes foo =bar. Ugh.
One of my subordinates writes code using a completely different style than I do, but that is at least consistent, so it's possible for me to look at. Another writes in some mish-mash of styles, completely inconsistent and hard to understand. And during code reviews I don't want to be too much of a pedant making a comment about every whitespace and inconsistently placed punctuation.
SourceForge project CVS access
What I started back then, I finished yesterday. I finally found the time to upload my ESMS project to SourceForge including CVS. I configured TortoiseCVS to work via SSH on my home PC, and it all ticks nicely. At least at first sight, TortoiseCVS is a very nice tool which seems to be easy to use, integrating well with the Windows Explorer.
Memory manager
Today I did something I'm quite proud of. I'm working on an embedded project, coding in C for the Nios II FPGA-embedded processor by Altera. In embedded projects one has to be very careful with the heap and dynamic memory allocation. What happens if it fails for some reason ? So the memory the program will need throughout its lifetime must be carefully calculated. Moreover, the heap and the stack reside in the same segment and there's no guarantee that the heap won't just overrun the stack (or vice versa) in cases of extreme memory shortage (and coding "bare", without an OS, this can lead to some spectacularly nasty bugs).
To make life simpler, I adapted an implementation of a memory manager (replacement for malloc() and free()) from K&R; 2 to use a fixed size static buffer as a pool (instead of calling sbrk()). After some testing, I think it now works well. So now instead of worrying that a runaway heap will run over the stack, I can happily contain it to a pre-allocated static buffer, where it will peacefully live. Moreover, I'll be able to reliably test an out-of-memory condition, without any disasters.