Hacker News Reader

Comment by cperciva | Hacker News Reader

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?

View on HN

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

> 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

Tossing everything into a single file is not required.

You can use includes to have "a single file to add to the project", and still split your code in smaller, readable files.

See https://github.com/jedisct1/libhydrogen for example. It's a single-file crypto library from an application perspective, but everything was not stored into a single, hard-to-navigate file.

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.

Now do it on Mac, and windows, and dynamic and static, and install the libraries in the right place. It gets maddening.

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.

The compiler invocation above only creates a single object file.

No, but I can see why you thought so.

The invocation above creates one object file for each C source file, as temporary files, (in a Unix system you can watch it do this with a suitably powerful syscall tracer, presumably something similar is possible on non-Unix systems but I don't know exactly how)

Then it links them and produces the output you've mistaken for an "object file", then it deletes the temporary files.

Ah, probably the easiest way to deal with some translation unit edge cases. :(

> compilers can do better inter-procedure optimization resulting in machine code that is between 5% and 10% faster.

does this hold even when non-amalgated code uses `-flto` or equivalent flag?

I don't know what's the state of the art for link time optimization these days but I would assume that it's still somewhat more limited than compile-time optimization. You can usually be a lot more aggressive when you have the full context of the code being optimized.

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"

Except it still depends on libtomcrypt.

Hah! Yeah ok :-)

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.

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.

> 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.

Yeah because it's really hard to include multiple files in another project...

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.

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.

Reply on news.ycombinator.com