9cc: A Small C Compiler

It lists a goal as "compiling real-world programs such as the linux kernel"

The last time I investigated the linux kernel had so many gcc-isms that it was probably true that if you could compile the linux kernel, you could probably compile any program targeted to gcc.

Small 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, with GCC 7.3 on Ubuntu 18:

  int func()
  {
    return 0;
  }

  int main()
  {
    func(3);
    return 0;
  }

-std=c11 (as you're using) makes no difference.

The same is not true of C++: func() in C++ is a prototype definition. C++ supports (void) for compatibility with C, but even in nonsensical contexts: class::class(void);

Regarding 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 library and header files.

Even when linking, don't call "cc", but "$(CC)". You're relying on the implicit rule to compile your .c to .o which will use $(CC). $(CC) could be some ARM cross-compiler supplied by a distro. When you link using "cc", you end up using the build-machine's native compiler.

Write the build system like this is an awesome program that major distros will be eager to pick up, and make it easy for the package maintainer. :)

Speaking of CFLAGS, only set that conditionally; don't clobber it:

  CFLAGS ?= -O2   # Only if CFLAGS is not specified externally, use this default

for things that your program needs in order to build right, put that in other variables of your own:

  DIALECT_CFLAGS := -std=c11

  CFLAGS += $(DIALECT_CFLAGS)  # integrate external CFLAGS with our own.

Same deal with LDFLAGS. Both CFLAGS and LDFLAGS can include important things that cause a bad build if you mess with them.

Any compiler should because as a definition, int foo() { } does in fact inform us that the function can only be correctly called with no arguments.

Formally, this is not introduced into the scope as type information according to the language spec, but that's no reason not to warn about it informally.

> Memory management is important even for short-lived programs. It would bring burden to the OS if you invoke this kind of "short-lived, memory-management-free" programs multiple times.

All the memory is freed when the process exits. Why does it matter if you run the program multiple times?