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.