Have you written very long functions? If so, why?

Question

I am writing an academic project about extremely long functions in the Linux kernel.

For that purpose, I am looking for examples for real-life functions that are extremely long (few hundreds of lines of code), that you don't consider bad programming (i.e., they won't benefit from decomposition or usage of a dispatch table).

Have you ever written or seen such a code? Can you post or link to it, and give explanation of why is it so long?

I have been getting amazing help from the community here - any idea that will be taken into the project will be properly credited.

Thanks,

Udi

Infuse

You should probably make this community wiki, as this is a personal question. – Toil

He won't do it. And he is now posting dupes, which is not likely to help his research project. See his other posts for evidence. – Amadou

Right you are. I see you even made the same suggestion in one of his earlier topics. – Toil

Wasn't this asked yesterday or the day before? – Clotho

Made it community wiki. Didn't mean to duplicate; The previous questions were different. However, if you believe I should close or delete the question - I will do so. – Infuse

Answer 1

The longest functions that I have ever written all have one thing in common, a very large switch statement. There are times, when you have to switch on a long list of items and it would only make things harder to understand if you tried to refactor some of the options into a separate function. Having large switch statements makes the Cyclomatic complexity go through the roof, but it is often better than the alternative implementations.

Rowley

it would only make things harder to understand if you tried to refactor some of the options into a separate function I agree, but what about using a list of cases and a list of function pointers and mapping them? – Acreinch

Answer 2

It was the last one before I got fired.

Circassia

Answer 3

A previous job: An extremely long case statement, IIRC 1000+ lines. This was long before objects. Each option was only a few lines long. Breaking it up would have made it less clear. There were actually a pair of such routines doing different things to the same underlying set of data types.

Sorry, I don't have the code anymore and it isn't mine to post, anyway.

Iliad

Answer 4

The longest function that I didn't see as being horrible would be the key method of a custom CPU VM. As with @epotter, this involved a big switch statement. In fact I'd say a lot of method that I find resist being cleanly broken down or improved in readability involve switch statements.

Cannabis

Answer 5

Beside the performance, I think the size of the call stack in Kernel space is 8K (please verify the size). Also, as far as I know, code in kernel is fairly specific. If some code is unlikely to be re-used in the future why bother make it a function considering function call overhead.

Chomp

Answer 6

Unfortunately, you won't often find this type of subroutine checked in or posted somewhere if it's auto-generated during a build step using some sort of code generator.

So look for projects that have C generated from another language.

Fanlight

Answer 7

I could imagine that when speed is important (such as when holding some sort of lock in the kernel) you would not want to break up a function because of the overhead due to making a functional call. When compiled, parameters have to be pushed onto the stack and data has to be popped off before returning. Therefor you may have a large function for efficiency reasons.

Glowworm

Perhaps, but as Neil commented before - inlining is the answer to this problem. – Infuse