I'm trying to find an official notice of support (or a contrary notice)
for Clang++ and -D_FORTIFY_SOURCE=2.
The QEMU project ran into an issue recently  where Clang++
(3.5.0-9.fc22) failed to compile certain files because it does not have
definitions for __builtin_va_pack_len (and friends). This kicks up
errors when using glibc, cstdio and _FORTIFY_SOURCE together.
We still do not support __builtin_va_pack_len and friends (and other
semantic requirements of fortify that rely on details of GCC's phase
ordering). We provide other extensions that can be used to implement
(most of) the functionality of -D_FORTIFY_SOURCE, but the maintenance
cost to us of supporting those GCC builtins directly is sufficiently
high that we don't (currently) intend to do so.
That's fine. I want to avoid using something that doesn't have
first-class support, so "no" is every bit as useful as "yes" here.
When researching the problem, we ran across an llvm bug  where
Richard Smith states: "_FORTIFY_SOURCE + glibc + clang is not supported
and does not wois, so thanks!rk".
However, in testing Clang++ 3.7.0-1.fc23, I notice that
-D_FORTIFY_SOURCE does indeed appear to work. Is that a fluke, or do
modern versions (>3.5.0) of Clang actually support this combination?
Current glibc headers use __builtin_va_arg_* only for GCC 4.3 onwards,
and Clang claims to be GCC 4.2. It's still an unsupported combination,
and while it might compile, some of the checks are unlikely to work
because they require a frontend inliner to be useful (for instance, some
of them require __builtin_object_size to look through function call
boundaries before the frontend type information is erased). We have
heard reports from users that the combination of Clang and glibc fortify
is not currently useful for them.
I wonder what's going on for 3.5.0-9.fc22, then -- it's picking up those
definitions somehow. (Oh well, maybe not a mystery worth solving...?)
If it works for you and provides value, that's great, but you should be
aware that the support story is likely to be worse than usual for an
open-source project: all of the effort I can see on the Clang side for
fortify-like features is being directed towards creating a more
principled set of language extensions (and using them to implement
fortify-like features in various flavours of libc) rather than directly
supporting the existing GCC set. Some of these are a close or exact
match to the GCC extension (such as our support for
__builtin_object_size and __builtin_constant_p), and some are not (such
as our enable_if attribute and upcoming pass_object_size attribute).
I understand. I will discontinue usage of _FORTIFY_SOURCE entirely (when
using clang) instead of hoping that maybe it sometimes works and having
a pretty bad day when it doesn't.
Primarily, since I was having problems with an older version and it
"magically resolved" for newer versions, I wanted to make sure that the
info I had gleaned from the bug tracker was still the accurate picture.
Which... it appears to be, so thanks!