chibicc is now distributed in mainstream Linux package systems. It came to my attention that several distros package exposed a side effect of chibicc's method to search compiler-supplied headers:
|
|
|
static void add_default_include_paths(char *argv0) { |
|
// We expect that chibicc-specific include files are installed |
|
// to ./include relative to argv[0]. |
|
strarray_push(&include_paths, format("%s/include", dirname(strdup(argv0)))); |
|
|
Searching relatively with dirname() works fine for in-tree execution, but when the main executable is moved and executed from $PATH, (what installing typically do), dirname() returns "." instead [1], causing chibicc to search ./include first even for standard headers.
The quirk can lead to subtle compile errors, as demonstrated by the simple Dockerfile below: the current chibicc build from Fedora/Debian/Ubuntu package would mistakenly include the ./include/stdio.h file as if it was /usr/include/stdio.h, and prints out the wrong message.
chibicc_pkg_test.Dockerfile
## Pick a distro
#FROM fedora:42
#RUN dnf install -y chibicc gcc
#FROM debian:12-slim
#RUN apt-get update && apt-get install -y chibicc gcc
#FROM ubuntu:24.04
#RUN apt-get update && apt-get install -y chibicc gcc
COPY <<EOF /work/include/stdio.h
int puts(char *);
#define puts(_) puts("puts hijack")
EOF
COPY <<EOF /work/hello.c
#include <stdio.h>
int main(void) {
puts("hello");
}
EOF
WORKDIR /work/
RUN gcc hello.c -o hello_gcc
RUN chibicc hello.c -o hello_chibicc
RUN ./hello_gcc | grep hello
RUN ./hello_chibicc | grep hello
It's commonly agreed that issues only occur in packages shouldn't be the upstream's concern (and this is outside of chibicc's intended scope as an educational project), however it's probably not a coincidence that the initial packaging from Fedora, Debian, Ubuntu, Arch AUR (as well as Alpine's of my fork) all exposed the same quirk. I hope posting the issue here could reach more packagers interested in chibicc.
[1] POSIX manual:
If the pathname does not contain a '/', then dirname() shall return a pointer to the string ".".
chibicc is now distributed in mainstream Linux package systems. It came to my attention that several distros package exposed a side effect of chibicc's method to search compiler-supplied headers:
chibicc/main.c
Lines 52 to 57 in 90d1f7f
Searching relatively with
dirname()works fine for in-tree execution, but when the main executable is moved and executed from $PATH, (what installing typically do),dirname()returns"."instead [1], causing chibicc to search./includefirst even for standard headers.The quirk can lead to subtle compile errors, as demonstrated by the simple Dockerfile below: the current chibicc build from Fedora/Debian/Ubuntu package would mistakenly include the
./include/stdio.hfile as if it was/usr/include/stdio.h, and prints out the wrong message.chibicc_pkg_test.Dockerfile
It's commonly agreed that issues only occur in packages shouldn't be the upstream's concern (and this is outside of chibicc's intended scope as an educational project), however it's probably not a coincidence that the initial packaging from Fedora, Debian, Ubuntu, Arch AUR (as well as Alpine's of my fork) all exposed the same quirk. I hope posting the issue here could reach more packagers interested in chibicc.
[1] POSIX manual: