Most reused/versatile code

[Peterbjornx]

What piece of code that you have written did you reuse most often?

For me that would be my (doubly) linked list implementation, which I wrote for my previous kernel and I have since used it for:

• My current kernel
• Dutch computer science olympiad assignments
• My OS's GUI library and server
• A VT100 emulator firmware for a very old terminal (Z80 based)
• The software for a high-altitude balloon tracker ( linux on arm )
• Lots of small projects

I wrote it in such a way that I could use it in all of these projects without any modifications

[Bender]

This:

Code: Select all

/** NOTE: This function trashes the current position in file **/
/** Does no error checking either **/
long int GetFileSize(FILE* FilePointer)  {  
      fseek(FilePointer, 0L, SEEK_END);
      long int ReturnVal = ftell(FilePointer);
      fseek(FilePointer, 0L, SEEK_SET);
      return ReturnVal;
}

(Everywhere?)

[alexfru]

Spaces and semicolons probably beat everything else.

[no92]

Newlines. They still count as code and they beat semicolons (comments and blank lines ...)

Jokes aside, probably the code proposed by Bender is the one that I've used the most, too. Did anyone propose it to the guys who maintain glibc?

[iansjack]

I doubt it. After all, a single system call will give you the file size, and a lot of other information about a file, without trashing the position of the file pointer.

See also: https://www.securecoding.cert.org/confl ... w/42729539

[bluemoon]

data structures and algorithms should be reused most, due to its nature and pattern of an application.
Other than that, it's debug/logging routines.

[Antti]

This is not exactly on-topic but I have reimplemented "print decimal numbers" in assembly many times and it is always painful. My latest implementation printed numbers like this:

Code: Select all

                         "0"
                      "1234"    special case!
                    "12 123"
                   "123 123"
                 "1 123 123"
            "12 123 123 123"
"18 446 744 073 709 551 615"

And this is only for unsigned integers (from 8 to 64 bits) but still...

[Kevin]

Oh really? Programming non-trivial things in assembly is painful? If we only had been told before!

[Combuster]

I doubt it. After all, a single system call will give you the file size, and a lot of other information about a file, without trashing the position of the file pointer.

See also: https://www.securecoding.cert.org/confl ... w/42729539

I don't agree that "do this with posix" is a correct answer, because that would actually make the code less portable. The fact that posix ignores the "b" mode means that all files have all the properties of both text and binary files and therefore must support SEEK_END and character-accurate reporting. In addition, "need not support" does mean that fseek-ftell pairs work de-facto on other platforms - most importantly of which is windows, even though it might pose an implementation risk on operating systems you won't practically encounter.

In other words. KISS wins.

[iansjack]

In other words. KISS wins.

I quite agree. Most platforms provide a single API call to determine file size and this is the one to use (KISS). There is no guaranteed portable way to determine file size.

I'd also comment that resusable code most emphatically should include error checking, preferably wouldn't have side effects, and you would hope it would work with files larger than 2GB .

[alexfru]

There is no guaranteed portable way to determine file size.

Unless your fgetc()/fread() returns/sets EOF on a binary file later than the actual end of file is reached and unless it's not a real binary file, there certainly is.

[iansjack]

There is no guaranteed portable way to determine file size.

Unless....

Exactly.

I'm well aware that with a real file you can just read all the bytes until the end of the file. I'd rather stick needles in my eye.

Let's face it, if the OS provides an API to obtain the files size it's crazy not to use it.

[Antti]

Let's face it, if the OS provides an API to obtain the files size it's crazy not to use it.

Are you serious? I heard that writing portable code might be important for projects written in C. If we broke compatibility, it would be reasonable to do it thoroughly. It is quite lame to do it on such a small scale.

[alexfru]

There is no guaranteed portable way to determine file size.

Unless....

Exactly.

I'm well aware that with a real file you can just read all the bytes until the end of the file. I'd rather stick needles in my eye.

fseek() to positions 0, 1, 2, 4, 8, etc, fgetc(), check for errors. You get the top bit of the size. Similarly you get the rest.

[Candy]

I think for me the thing I find the least in existing libraries is having an idmap. A class that maps instances to IDs. You use it for any kind of hard interface where you want to give out handles and validate them when they come back - kernel boundary, remote calls, ... Biggest property is that they are usually small and that they are not reused or moved until freed.