`__builtin_dynamic_object_size` does not report size of function argument VLAs

[kees]

For function argument VLAs, GCC correctly reports the expected size. Clang seems unaware:

#include <stdio.h>

void __attribute__((noinline))
foo(int n, short array[n])
{
        printf("%zu\n", __builtin_dynamic_object_size(array, 1));
}

int main(void)
{
        short array[10];

        foo(10, array);
        return 0;
}

$ gcc -Wall -O2 -o fvla-gcc fvla.c && ./fvla-gcc
20
$ clang -Wall -O2 -o fvla-clang fvla.c && ./fvla-clang
18446744073709551615

@bwendling

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Kees Cook (kees)

For function argument VLAs, GCC correctly reports the expected size. Clang seems unaware:

#include <stdio.h>

void __attribute__((noinline))
foo(int n, short array[n])
{
        printf("%zu\n", __builtin_dynamic_object_size(array, 1));
}

int main(void)
{
        short array[10];

        foo(10, array);
        return 0;
}

$ gcc -Wall -O2 -o fvla-gcc fvla.c && ./fvla-gcc
20
$ clang -Wall -O2 -o fvla-clang fvla.c && ./fvla-clang
18446744073709551615

@bwendling

[efriedma-quic]

Don't you need foo(int n, short array[static n])? By default, the bound of an array before adjustment doesn't have any semantic effect.

[kees]

That shouldn't matter (this is about the runtime size: bos has no idea with or without static, but bdos has what it needs to figure it out). And Clang doesn't emit the right answer in that case either. :P

[efriedma-quic]

Let's simplify:

#include <stdio.h>
void foo(short array[10])
{
        printf("%zu\n", __builtin_object_size(array, 1));
}

clang and gcc both agree the size is unknown, because this is semantically exactly the same as void foo(short* array).

I don't see how bdos or VLAs change that analysis.

[kees]

Today, I agree with you about void foo(short array[10]). I hope to revisit that in the future, but for now, I want to get parity with GCC, as the VLA prototype is explicitly saying how large the argument is. This is the same conceptual information as counted_by on pointer members in a struct.

There can be a separate bug about literal values, and that will be the precursor for handling the single function argument attribute (which is detailed in the -fbounds-safety RFC), which will end up being conceptually identical to void foo(short array[1]). With literals, the size information can actually be available to bos.

But one thing at a time. :) First, let's get function argument VLAs wired up to bdos to match GCC.

[efriedma-quic]

You're saying that bdos has some special semantics that say we should pretend we know the size of the object pointed to by pointers declared in a certain way, even though there's no semantic rule that actually specifies the size, and there's no documentation anywhere that says this is supposed to happen?

I think this breaks our normal rules for new extensions, which is that they have to have some reserved extension marker. I mean, technically there's a marker when you call bdos, but that's not helpful when someone's code breaks because FORTIFY starts using bdos internally.

[kees]

I feel like we're talking past each other, but this is for use with FORTIFY: it is the primary (only?) user of bdos. It is expecting to tie declared object size information to pointers, and this is what we have here: the variable is an array with a specific size. FORTIFY is just waiting for bdos to gain this awareness. The whole point of the bounds-safety work is to fix these gaps in object size awareness so that bdos and the sanitizers gain access to the size information that has been semantically expressed in the language.

[efriedma-quic]

You can't just declare a standard C construct "specifies the size" when the standard says it does not, in fact, specify the size. Like, we can't say int ((*x)); points to an object of exactly 4 bytes because there are four parentheses in the declarator.

[kees]

But bdos is not part of the standard. We can make changes to language extensions, especially to maintain interoperability with GCC.

[kees]

You can't just declare a standard C construct "specifies the size" when the standard says it does not, in fact, specify the size. Like, we can't say int ((*x)); points to an object of exactly 4 bytes because there are four parentheses in the declarator.

Also, this seems like an unreasonable slippery slope argument. If source code shows an array of size 4, it is perfectly reasonable to expect that it is, in fact, an array of size 4.