5 ms·

I don't understand the fascination with "single file" libraries. Sure, you can take a well organized tree of a few dozen C files and turn it into a single ten-

I don't understand the fascination with "single file" libraries. Sure, you can take a well organized tree of a few dozen C files and turn it into a single ten-thousand-line monstrosity, but why on earth would you want to?

skrebbel 8y ago
I agree with you, but I guess you know that the answer is "because c still has no proper dependency manager so downloading a c file and adding it to the project/makefile/etc is often the easiest way forward"
- tedunangst 8y ago
  Except it still depends on libtomcrypt.
  - skrebbel 8y ago
    Hah! Yeah ok :-)
cjhanks 8y ago
If you are working on embedded software in an environment without robust dependency management, dropping in a file is the easiest way to add a feature. You also may want to minimize symbol leakage into a C program, a single file allows most functions and constants to become static.
throwaway12iii 8y ago
It's very common in the C/C++ world. The main reason is that you can easily use it in other projects. Until one of the C/C++ package managers gets good and wins, this is the nicest alternative. Note that people don't necessarily develop the libraries in one big file or don't have dependencies. Many newer libraries use a single C file as a distribution format. The other nice thing about it is that if the code is small it can be more easily debugged and audited by humans. If it pulls in hundreds of thousands of lines of code, that can be a problem. Also, small code is a requirement on some projects because of speed or memory limitations.
- black-tea 8y ago
  Yeah because it's really hard to include multiple files in another project...
- frutiger 8y ago
  > The other nice thing about it is that if the code is small it can be more easily debugged and audited by humans. The size of the code is independent of the number of files the code is in.
chrisseaton 8y ago
It's very useful in some parts of CS research to have be able to bypass complex build and linking systems and just be able to run an instrumented C compiler of some sorts. I think it's also people giving up on build systems and package managers.
simias 8y ago
Because C has no package system and it sucks, and having a single file (ideally with no dependencies, which isn't the case here) makes it super easy to integrate it anywhere. A good example of that IMO is cJSON[1], it's a small self-contained single file implementation of a JSON reader and parser. It's easy to use, the code is pretty clean and easy to follow and I never ran into any obvious limitation. I very much recommend it. There are also projects that are developed as multiple files but amalgamated into a single huge file before release. SQLite does that: https://sqlite.org/amalgamation.html https://sqlite.org/amalgamation.html > Over 100 separate source files are concatenated into a single large files of C-code named "sqlite3.c" and called "the amalgamation". The amalgamation contains everything an application needs to embed SQLite. The amalgamation file is more than 220,000 lines long and over 7.5 megabytes in size (as of 2018-11-24). > Combining all the code for SQLite into one big file makes SQLite easier to deploy — there is just one file to keep track of. And because all code is in a single translation unit, compilers can do better inter-procedure optimization resulting in machine code that is between 5% and 10% faster. [1] https://github.com/DaveGamble/cJSON https://github.com/DaveGamble/cJSON
- peterwwillis 8y ago
  gcc -shared -o mycrypto.1.1.so file1.c file2.c file3.c file4.c #include "mycrypto.1.1.h" Doesn't that have the same effect of being easy to include? The amalgamation may be better for the compiler but I'm not sure why.
  - tialaramex 8y ago
    A platform has a fixed ABI that says e.g. the first integer parameter to a function goes in register R14, the sixth one goes on the stack. If you have sixty C files the compiler is obliged to produce sixty object files which each obey that ABI for all their functions because you might stitch in some other code, not using that compiler at all, which obeys the ABI and if you ignore the rules this will unexpectedly not work. But within a single object the compiler doesn't need to obey the ABI rule at all if that's faster. Now, you obviously could imagine an object and more powerful linkers that had enough optimisation magic to produce the same output executable from the sixty object files, but just spitting out a single source code file is a LOT easier than making that optimisation work on every platform now and in the future.
flukus 8y ago
It's a failure of collaboration. For most single file libraries it would be better to have them bundled into a larger networking library that covers enough functionality to make adding and managing the dependency worthwhile. Eventually there will be a security vulnerability found and every app will be on some random version making it exploitable.

skrebbel 8y ago

I agree with you, but I guess you know that the answer is "because c still has no proper dependency manager so downloading a c file and adding it to the project/makefile/etc is often the easiest way forward"

tedunangst 8y ago
Except it still depends on libtomcrypt.
- skrebbel 8y ago
  Hah! Yeah ok :-)

cjhanks 8y ago

If you are working on embedded software in an environment without robust dependency management, dropping in a file is the easiest way to add a feature. You also may want to minimize symbol leakage into a C program, a single file allows most functions and constants to become static.

throwaway12iii 8y ago

It's very common in the C/C++ world. The main reason is that you can easily use it in other projects. Until one of the C/C++ package managers gets good and wins, this is the nicest alternative. Note that people don't necessarily develop the libraries in one big file or don't have dependencies. Many newer libraries use a single C file as a distribution format. The other nice thing about it is that if the code is small it can be more easily debugged and audited by humans. If it pulls in hundreds of thousands of lines of code, that can be a problem. Also, small code is a requirement on some projects because of speed or memory limitations.

black-tea 8y ago
Yeah because it's really hard to include multiple files in another project...
frutiger 8y ago
> The other nice thing about it is that if the code is small it can be more easily debugged and audited by humans. The size of the code is independent of the number of files the code is in.

chrisseaton 8y ago

It's very useful in some parts of CS research to have be able to bypass complex build and linking systems and just be able to run an instrumented C compiler of some sorts. I think it's also people giving up on build systems and package managers.

simias 8y ago

Because C has no package system and it sucks, and having a single file (ideally with no dependencies, which isn't the case here) makes it super easy to integrate it anywhere. A good example of that IMO is cJSON[1], it's a small self-contained single file implementation of a JSON reader and parser. It's easy to use, the code is pretty clean and easy to follow and I never ran into any obvious limitation. I very much recommend it. There are also projects that are developed as multiple files but amalgamated into a single huge file before release. SQLite does that: https://sqlite.org/amalgamation.html https://sqlite.org/amalgamation.html > Over 100 separate source files are concatenated into a single large files of C-code named "sqlite3.c" and called "the amalgamation". The amalgamation contains everything an application needs to embed SQLite. The amalgamation file is more than 220,000 lines long and over 7.5 megabytes in size (as of 2018-11-24). > Combining all the code for SQLite into one big file makes SQLite easier to deploy — there is just one file to keep track of. And because all code is in a single translation unit, compilers can do better inter-procedure optimization resulting in machine code that is between 5% and 10% faster. [1] https://github.com/DaveGamble/cJSON https://github.com/DaveGamble/cJSON

peterwwillis 8y ago
gcc -shared -o mycrypto.1.1.so file1.c file2.c file3.c file4.c #include "mycrypto.1.1.h" Doesn't that have the same effect of being easy to include? The amalgamation may be better for the compiler but I'm not sure why.
- tialaramex 8y ago
  A platform has a fixed ABI that says e.g. the first integer parameter to a function goes in register R14, the sixth one goes on the stack. If you have sixty C files the compiler is obliged to produce sixty object files which each obey that ABI for all their functions because you might stitch in some other code, not using that compiler at all, which obeys the ABI and if you ignore the rules this will unexpectedly not work. But within a single object the compiler doesn't need to obey the ABI rule at all if that's faster. Now, you obviously could imagine an object and more powerful linkers that had enough optimisation magic to produce the same output executable from the sixty object files, but just spitting out a single source code file is a LOT easier than making that optimisation work on every platform now and in the future.

flukus 8y ago

It's a failure of collaboration. For most single file libraries it would be better to have them bundled into a larger networking library that covers enough functionality to make adding and managing the dependency worthwhile. Eventually there will be a security vulnerability found and every app will be on some random version making it exploitable.