I wonder if this is a reference to the band 10cc - https://en.wikipedia.org/wiki/10cc
From the 2015 discussion about 8cc, the author states that "I chose a random character to append before 'cc'."
9cc: A Small C Compiler
21–30 of 70 posts
Re: 9cc: A Small C Compiler
#22Earlier quoted context omitted.
It will put more pressure on the allocator when running, doing that a lot will likely have some kind of cumulative consequence down the line. I know from experience [0] that even reusing allocated memory rather than bouncing it back to malloc can have dramatic effects. [0] https://gitlab.com/sifoo/snigl/blob/master/src/snigl/pool.h
Sure, but if you're not freeing memory you don't need a real malloc. You allocation function can be just "top += allocsize".
Yes, that's commonly known as "arena allocation" and has been used for decades in programs that have well-defined phases that create lots of connected objects with the same lifetime, like compiler passes, RPC serialization layers, or query planners.
Re: 9cc: A Small C Compiler
#23Regarding your Makefile; you should still pass CFLAGS through to the compiler when linking, not only LDFLAGS. Suppose CFLAGS contains -m32 (supported by an x86-64-targetted GCC to do 32 bit). You compile the .o files with that, but then link without it, which fails trying to make a 64 bit executable out of 32 bit .o's. Some crazy distros pass a --sysroot in CFLAGS; if you don't have that, your build finds the wrong l…
Where would one go to find more of this conventional Makefile wisdom? I've had so many issues trying to use make the "right" way (flexible, clean, terse, etc.).
I feel like one of the best ways to acquire this wisdom is to post a project with lots of mistakes and let people tear it apart.
Re: 9cc: A Small C Compiler
#24Good to see more C/subset-C compilers being written. Besides the immense pedagogical value, they are also useful for preventing the "trusting trust" attack: https://dwheeler.com/trusting-trust/ I will also make a suggestion to use precedence climbing instead of plain recursive descent for the parser; it makes the parser even simpler and table-driven, which is important with a language like C that has many precedence…
Interesting, do you have any useful links related to this concept?
Re: 9cc: A Small C Compiler
#25Regarding your Makefile; you should still pass CFLAGS through to the compiler when linking, not only LDFLAGS. Suppose CFLAGS contains -m32 (supported by an x86-64-targetted GCC to do 32 bit). You compile the .o files with that, but then link without it, which fails trying to make a 64 bit executable out of 32 bit .o's. Some crazy distros pass a --sysroot in CFLAGS; if you don't have that, your build finds the wrong l…
Where would one go to find more of this conventional Makefile wisdom? I've had so many issues trying to use make the "right" way (flexible, clean, terse, etc.). I feel like one of the best ways to acquire this wisdom is to post a project with lots of mistakes and let people tear it apart.
I got it from working on lots of C for almost thirty years, and also by putting together a from-scratch embedded GNU/Linux distro some decade ago, and more recently doing distro work also.
As far as knowing GNU Make, I recommend just reading the manual from beginning to end, perhaps twice.
Re: 9cc: A Small C Compiler
#26Good to see more C/subset-C compilers being written. Besides the immense pedagogical value, they are also useful for preventing the "trusting trust" attack: https://dwheeler.com/trusting-trust/ I will also make a suggestion to use precedence climbing instead of plain recursive descent for the parser; it makes the parser even simpler and table-driven, which is important with a language like C that has many precedence…
Interesting, do you have any useful links related to this concept?
Here is the discussion of the original Trusting Trust attack: https://news.ycombinator.com/item?id=13569275
Re: 9cc: A Small C Compiler
#27Re: 9cc: A Small C Compiler
#28I wonder if this is a reference to the band 10cc - https://en.wikipedia.org/wiki/10cc
G is the 7th letter of the alphabet
Re: 9cc: A Small C Compiler
#29Small nitpick. Functions in C that take no arguments are written name(void){...} not name(){...}. This latter form is an old-style definition which doesn't introduce a prototype into the scope. For functions that have prototypes, it is okay, but when they do not, you're losing type checking (yes, even on the number of arguments). The following program compiles with no diagnostics for me with -W -Wall -ansi -pedantic,…
Quote from 6.7.6.3.14 of the C++11 spec (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf):
> An identifier list declares only the identifiers of the parameters of the function. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.
So, my interpretation is that the following two function definitions define the same function of the exact same type
void func() {}
void func(void) {}
void func();
void func(void);Re: 9cc: A Small C Compiler
#30Good to see more C/subset-C compilers being written. Besides the immense pedagogical value, they are also useful for preventing the "trusting trust" attack: https://dwheeler.com/trusting-trust/ I will also make a suggestion to use precedence climbing instead of plain recursive descent for the parser; it makes the parser even simpler and table-driven, which is important with a language like C that has many precedence…
Interesting, do you have any useful links related to this concept?
Thompson publicized an attack by Paul Karger during MULTICS. One of many. Defeating their totality took what's called high-assurance security. For compilers, you have to verify source despite potentially-malicious developers, verify its binary translation, and its distribution. Maybe the tools used to do that as well. I wrote more about what that takes here:
https://lobste.rs/s/nognrl/creating_language_using_only_asse...