Large single compilation-unit C programs (2006)

#1

Post by Sadkov » Thu, Oct 08, 2020, 8:21 AM UTC

Large single compilation-unit C programs (2006)
people.csail.mit.edu

Re: Large single compilation-unit C programs (2006)

#2

Post by Sadkov » Thu, Oct 08, 2020, 8:31 AM UTC

1283 = continue 1432 = license 1766 = gnu

So for every loop continue statement there is a GPL license text :D

Re: Large single compilation-unit C programs (2006)

#3

Post by lou1306 » Fri, Oct 09, 2020, 8:34 AM UTC

May be relevant to the discussion: SQLite is also compiled from a single, 220k LOC C file called "the amalgamation".

https://www.sqlite.org/amalgamation.html

Re: Large single compilation-unit C programs (2006)

#4

Post by dvfjsdhgfv » Fri, Oct 09, 2020, 9:05 AM UTC

Sadkov wrote: post #2

1283 = continue 1432 = license 1766 = gnu So for every loop continue statement there is a GPL license text :D

I know it's half serious but it's simply not true, in the same way as grepping for "Stallman" in the leaked Windows source code (nobody actually mentioned RMS there, these were false positives). In this case, some headers contain multiple occurrences of GNU in a single header. Then there are several #ifdefs like "__GNU_LIBRARY__" or "__GNUC__" or e-mail addresses of people in the gnu.org domain.

In practice, it doesn't matter at all as the preprocessor replaces all license headers with a single space even before the compiler has the chance to look at it.

Re: Large single compilation-unit C programs (2006)

#5

Post by dhekir » Fri, Oct 09, 2020, 9:20 AM UTC

lou1306 wrote: post #3

May be relevant to the discussion: SQLite is also compiled from a single, 220k LOC C file called "the amalgamation". https://www.sqlite.org/amalgamation.html

I also found this "amalgamate" script on GitHub, intended to allow creating such amalgamations from C/C++ projects:

https://github.com/rindeal/Amalgamate

Which seems interesting, however when I tried the FreeType example, there seemed to be some preprocessing issue, such that some function definitions are conditionally excluded even though they are called later. I didn't have the time to find out if this was an issue in the original code or if the amalgamation script introduced it.

In any case, such single-C programs are very useful for quickly testing tools, so having more of them would be great.

Re: Large single compilation-unit C programs (2006)

#6

Post by enriquto » Fri, Oct 09, 2020, 10:26 AM UTC

I like to code this way. You just include "foo.c" instead of "foo.h", which does not exist at all. The compilation is really simple, and there's half of the files!

Re: Large single compilation-unit C programs (2006)

#7

Post by colejohnson66 » Fri, Oct 09, 2020, 10:50 AM UTC

dvfjsdhgfv wrote: post #4

Sadkov wrote: post #2

1283 = continue 1432 = license 1766 = gnu So for every loop continue statement there is a GPL license text :D

I know it's half serious but it's simply not true, in the same way as grepping for "Stallman" in the leaked Windows source code (nobody actually mentioned RMS there, these were false positives). In this case, some headers contain multiple occurrences of GNU in a single header. Then there are several #ifdefs like "__GNU_LIBRARY__" or "__GNUC__" or e-mail addresses of people in the gnu.org domain. In practice, it doesn…

The preprocessor removes the comments? I thought that was the compiler?

Re: Large single compilation-unit C programs (2006)

#8

Post by zabzonk » Fri, Oct 09, 2020, 10:53 AM UTC

colejohnson66 wrote: post #7

dvfjsdhgfv wrote: post #4

Earlier quoted context omitted.

I know it's half serious but it's simply not true, in the same way as grepping for "Stallman" in the leaked Windows source code (nobody actually mentioned RMS there, these were false positives). In this case, some headers contain multiple occurrences of GNU in a single header. Then there are several #ifdefs like "__GNU_LIBRARY__" or "__GNUC__" or e-mail addresses of people in the gnu.org domain. In practice, it doesn…

The preprocessor removes the comments? I thought that was the compiler?

Nope. See https://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC2

Re: Large single compilation-unit C programs (2006)

#9

Post by gridlockd » Fri, Oct 09, 2020, 10:55 AM UTC

dvfjsdhgfv wrote: post #4

Sadkov wrote: post #2

1283 = continue 1432 = license 1766 = gnu So for every loop continue statement there is a GPL license text :D

I know it's half serious but it's simply not true, in the same way as grepping for "Stallman" in the leaked Windows source code (nobody actually mentioned RMS there, these were false positives). In this case, some headers contain multiple occurrences of GNU in a single header. Then there are several #ifdefs like "__GNU_LIBRARY__" or "__GNUC__" or e-mail addresses of people in the gnu.org domain. In practice, it doesn…

The preprocessor doesn't remove comments and at least in clang, comments are parsed into the AST.

Re: Large single compilation-unit C programs (2006)

#10

Post by dvfjsdhgfv » Fri, Oct 09, 2020, 11:36 AM UTC

gridlockd wrote: post #9

dvfjsdhgfv wrote: post #4

Earlier quoted context omitted.

I know it's half serious but it's simply not true, in the same way as grepping for "Stallman" in the leaked Windows source code (nobody actually mentioned RMS there, these were false positives). In this case, some headers contain multiple occurrences of GNU in a single header. Then there are several #ifdefs like "__GNU_LIBRARY__" or "__GNUC__" or e-mail addresses of people in the gnu.org domain. In practice, it doesn…

The preprocessor doesn't remove comments and at least in clang, comments are parsed into the AST.

Well, according to C99, it should. Section "5.1.1.2 Translation phases" says (in phase 3): "Each comment is replaced by one space character."

Edit: just checked and clang behaves just like gcc with -E. Maybe you didn't mean comments but preprocessor directives?