Clang++ and _FORTIFY_SOURCE: Supported or not?

Hi, all:

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 [1] 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.

When researching the problem, we ran across an llvm bug [2] where
Richard Smith states: "_FORTIFY_SOURCE + glibc + clang is not supported
and does not work".

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?

I can't find official documentation pointing towards either support or
exclusion of this feature, so a firm answer pointing to either direction
would be helpful.

Thank you,
--John Snow

[1] QEMU discussion:
https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06997.html
[2] https://llvm.org/bugs/show_bug.cgi?id=23277#c2

Hi, all:

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 [1] 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.

When researching the problem, we ran across an llvm bug [2] where

Richard Smith states: "_FORTIFY_SOURCE + glibc + clang is not supported
and does not work".

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.

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 can't find official documentation pointing towards either support or

    Hi, all:

    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 [1] 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 [2] 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!

--js

I would be very interested in hearing if you have any examples where FORTIFY_SOURCE detects errors that the clang static analyser does not catch.

David