5

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

Community
  • 1
  • 1
Adam Matan
  • 128,757
  • 147
  • 397
  • 562
  • 3
    You should probably make this community wiki, as this is a personal question. – Brandon Jul 17 '09 at 16:26
  • 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. –  Jul 17 '09 at 16:38
  • Right you are. I see you even made the same suggestion in one of his earlier topics. – Brandon Jul 17 '09 at 16:41
  • Wasn't this asked yesterday or the day before? – Sam Harwell Jul 17 '09 at 16:45
  • 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. – Adam Matan Jul 17 '09 at 17:18

7 Answers7

10

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.

epotter
  • 7,631
  • 7
  • 63
  • 88
  • `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? – Vorac May 22 '19 at 11:51
4

It was the last one before I got fired.

Darius
  • 524
  • 1
  • 5
  • 11
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.

Loren Pechtel
  • 8,945
  • 3
  • 33
  • 45
2

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.

David
  • 24,700
  • 8
  • 63
  • 83
1

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.

Drew Hoskins
  • 4,168
  • 20
  • 23
1

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.

Quincy
  • 1,923
  • 5
  • 27
  • 37
0

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.