Easily fix buffer overruns!

Has your project ever been bitten by hard-to-track down buffer overruns?

Have you ever wanted to be able to just ignore buffer overruns and make them a thing of the past?

Are you ok with wasting memory to work around this problem? ¹

Well, your wish has now been answered, thanks to malloc-extra!

This handy little shared library will allocate a trailing amount of buffer space for every allocation, ensuring that your pesky buffer overruns will just land in safely unused and reserved space.

malloc-extra simply uses some dynamic library magic to intercept every malloc, calloc, and realloc your program will call, and just request slightly more space than the original requester was chasing. From the point of view of the caller of these functions - they don’t know this extra space exists, meaning that it can be a transparent fix to already compiled programs!

MALLOC_EXTRA_DEBUG=1 MALLOC_EXTRA=100 LD_PRELOAD=./malloc-extra.so ./test

Fast tab-switching in vim

Working with a lot of different code bases means working with a lot of different coding styles. When code uses tab characters for indenting it makes things a lot easier - it lets the user decide how deep they would like each indent level to be. With the following macro I can change the display with of tab characters from the file’s default (often set with a vim modeline) to 1 character. This helps massively with deeply nested code and fitting everything on to one screen.

This code snippet maps the F8 key to a function, s:ToggleTabs() that toggles tabs in the current vim buffer between being the default width and being one character wide. The s: makes sure the function is local to the current script to avoid clashing with other plugins.

It sets the vim variables tabstop, shiftwidth and softtabstop to ensure that tabs behave consistently in display, when shift and when in insert mode. They’re set in a buffer-local context (that’s the b: prefix) to ensure they only affect the current buffer.

"map <F8> to toggle small/normal tabs
noremap <F8> :call <SID>ToggleTabs()<CR>

"Toggles tab size between the default width and 1 character width
"b: buffer-local variables
"&l: buffer-local options
"see :help internal-variables
function! s:ToggleTabs  ()
	if !exists("b:tab_toggler_large")
		let b:tab_toggler_large = 1
	endif
	if b:tab_toggler_large == 0 
		let b:tab_toggler_large = 1	
		let &l:ts = b:tab_toggler_ts
		let &l:sw = b:tab_toggler_sw
		let &l:sts = b:tab_toggler_sts
	else
		"save the previous tab settings
		let b:tab_toggler_large = 0
		let b:tab_toggler_ts = &ts
		let b:tab_toggler_sw = &sw
		let b:tab_toggler_sts = &sts
		let &l:ts = 1
		let &l:sw = 1
		let &l:sts = 1
	endif
endfunction

Eudyptula Challenge

Learning is always easier when you have a goal. If you’ve ever wanted to get started with Linux kernel development, but haven’t had a clear goal in mind, give the Eudyptula Challenge a go.

I’m the 22nd person to have finished the Eudyptula Challenge. It’s a series of (currently 20) challenges, increasing in difficulty, designed to introduce and educate the participant in the methods, techniques and code-base surrounding the Linux kernel and it’s development. It’s not a tutorial however, the challenges are posed, and it’s upon the participant to investigate and learn enough to complete the challenge. As a result, public discussion of specific questions is discouraged.

Subject matter ranges from building custom kernels, coding style modifications, patch submission, locking mechanisms, networking and file-systems. It’s a good broad stroke introduction to developing in the kernel.

Some challenges were relatively trivial, others less so. The final challenge in particular was a dramatic step-up in difficulty. In some cases, gathering the ‘proof’ required to demonstrate your solution was working was substantially more complicated than the solution itself.

The challenge all takes place over email, mirroring the patch submission process for the Linux kernel. It requires an email client that’s capable of sending plain text emails (there are notes out there for most clients on how to make this happen). Submissions are somewhat automatically reviewed, although several definitely require a person to critique the solution.

There are a few other sites popping up around the challenge that are talking about it. There’s a great article over at Linux Weekly News that covers another’s experience with the challenge.

I’ve certainly learnt a lot from working through the challenge, and I’d think that most developers would learn something. It’s a fun and enjoyable project to have ticking along in the background. Give it a go!