llvm dev - Apr 2021 - Why does clang -E - of a header file may have different exit status?

I see different exit status of clang. Does anybody know why? Should
clang be consistent on this aspect no matter what the header file is?

$ clang -E - <<< '#include <bfd.h>' | head -n 1
# 1 "<stdin>"
$ declare -p PIPESTATUS
declare -a PIPESTATUS=([0]="141" [1]="0")
$ clang -E - <<< '#include <stdio.h>' | head -n 1
# 1 "<stdin>"
$ declare -p PIPESTATUS
declare -a PIPESTATUS=([0]="0" [1]="0")
$ clang --version
Debian clang version 11.0.1-2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

gcc's exit status is consistent in this case.

$ gcc -E - <<< '#include <stdio.h>' | head -n 1
# 1 "<stdin>"
$ declare -p PIPESTATUS
declare -a PIPESTATUS=([0]="2" [1]="0")
$ gcc -E - <<< '#include <bfd.h>' | head -n 1
# 1 "<stdin>"
$ declare -p PIPESTATUS
declare -a PIPESTATUS=([0]="2" [1]="0")
$ gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- 
Regards,
Peng

I mean, looks like clang exits non-zero when trying to preprocess your
bfd.h? Does clang print any errors? Maybe try reducing down the
contents of bfd.h to see what's critical about the contents of that
file that causes the non-zero exit?

On Thu, Apr 29, 2021 at 8:04 PM Peng Yu via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> I see different exit status of clang. Does anybody know why? Should
> clang be consistent on this aspect no matter what the header file is?
>
> $ clang -E - <<< '#include <bfd.h>' | head -n 1
> # 1 "<stdin>"
> $ declare -p PIPESTATUS
> declare -a PIPESTATUS=([0]="141" [1]="0")
> $ clang -E - <<< '#include <stdio.h>' | head -n 1
> # 1 "<stdin>"
> $ declare -p PIPESTATUS
> declare -a PIPESTATUS=([0]="0" [1]="0")
> $ clang --version
> Debian clang version 11.0.1-2
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
>
> gcc's exit status is consistent in this case.
>
> $ gcc -E - <<< '#include <stdio.h>' | head -n 1
> # 1 "<stdin>"
> $ declare -p PIPESTATUS
> declare -a PIPESTATUS=([0]="2" [1]="0")
> $ gcc -E - <<< '#include <bfd.h>' | head -n 1
> # 1 "<stdin>"
> $ declare -p PIPESTATUS
> declare -a PIPESTATUS=([0]="2" [1]="0")
> $ gcc --version
> gcc (Debian 10.2.1-6) 10.2.1 20210110
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> --
> Regards,
> Peng
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 30/04/2021 04:04, Peng Yu via llvm-dev wrote:
> I see different exit status of clang. Does anybody know why? Should
> clang be consistent on this aspect no matter what the header file is?
> 
> $ clang -E - <<< '#include <bfd.h>' | head -n 1
> # 1 "<stdin>"
> $ declare -p PIPESTATUS
> declare -a PIPESTATUS=([0]="141" [1]="0")
$ kill -l 141
PIPE

This happens because clang failed to fully write the preprocessed output 
because the head command is no longer accepting more input. This is not 
specific to clang, it happens with many other utilities as well. Once 
the head command is no longer accepting more input, it's pointless for 
clang to continue writing output, so it's sent a signal to stop.

Depending on the contents of the header file, the signal to stop may be 
sent before or after clang has already fully written its output. If it 
has fully written the output already, then clang will not notice any 
error and exit successfully. This matches GCC, except that you need 
different header files to show this with GCC. Try a tiny header file 
such as <stdbool.h> instead.

Cheers,
Harald van Dijk