Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: this girl calls c ugly Date: Fri, 05 Jun 2026 05:49:58 -0700 Organization: A noiseless patient Spider Lines: 41 Message-ID: <86fr31b18p.fsf@linuxsc.com> References: <10v7b32$2u85v$1@dont-email.me> <10vd1tu$ekvl$1@dont-email.me> <10vel6r$l1g$1@reader1.panix.com> <10vemqf$r5qe$1@dont-email.me> <10vfsmo$16jap$1@kst.eternal-september.org> <10vgqhf$1d6tp$1@dont-email.me> <86tsrnefac.fsf@linuxsc.com> <10vhq39$1lpo1$1@dont-email.me> <86zf1fc8oq.fsf@linuxsc.com> <10vjltg$255kd$1@dont-email.me> <86a4tad4xo.fsf@linuxsc.com> <10vro7t$bjmf$1@dont-email.me> <10vrred$74ie$1@dont-email.me> <10vrtud$d8gc$1@dont-email.me> <10vs20g$d992$1@dont-email.me> <3zhUR.2$8Em1.0@fx42.iad> <10vsdnd$fm4o$1@dont-email.me> <10vsnfg$lahf$1@dont-email.me> <10vspuu$lkmu$3@kst.eternal-september.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 05 Jun 2026 12:50:00 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1196270"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/79U90/Ti8R8uJZ2ngeGKXeWaCisiYOaU="; posting-host="ab312f3c60546a52db3a021dc13141bd" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:/DcjrdtaS8HHTmNJP3WFqAJwrXg= sha1:k+wS5E6uQHb23N5ZHdk7ng2Zhd4= sha256:xUK+zxZlTettSoB+AUvIUEx2UOKT8/Hy/DhsRdx+yz8= sha1:Z4waxsXdovmlJ96pfK3RWN2KTFk= Xref: csiph.com comp.lang.c:399746 Keith Thompson writes: > James Kuyper writes: > [...] > >> One advantage of having a single program do the whole thing, is >> that error messages can mention the actual text of the line where >> a problem was detected, without any pre-processing applied. > > Typical preprocessors emit directives that tell the compiler > about the current file name and line number, precisely so that > diagnostic messages can refer to the original text. > > For example: > > $ cat hello.c > #include > int main(void) { > printf("Hello world!\n"); > } > $ gcc -E hello.c | tail > extern int __uflow (FILE *); > extern int __overflow (FILE *, int); > # 983 "/usr/include/stdio.h" 3 4 > > # 2 "hello.c" 2 > > # 2 "hello.c" > int main(void) { > printf("Hello world!\n"); > } > $ > > The line `# 2 "hello.c"` is, according to the C standard, a > "non-directive", which is a kind of directive. Executing a > non-directive has undefined behavior, Since it is gcc that is generating the non-directives, for internal purposes, and gcc that is consuming them, it hardly seems worth worrying about whether their behavior is defined or not.