Linux 6.8 Now Enables -Wstringop-overflow To Warn About Buffer Overflows

[phoronix]

Phoronix: Linux 6.8 Now Enables -Wstringop-overflow To Warn About Buffer Overflows

A change merged today for the Linux 6.8 kernel intentionally following yesterday's Linux 6.8-rc1 is a move to enable the "-Wstringop-overflow" compiler option by default...

https://www.phoronix.com/news/Linux-6.8-Wstringop-overflow

[kylew77]

WOW! How can a C compiler do this, "This will provide a compiler warning for known cases where calls to the likes of strcpy or memcpy would for certain yield a buffer overflow."?

[guspitts]

WOW! How can a C compiler do this, "This will provide a compiler warning for known cases where calls to the likes of strcpy or memcpy would for certain yield a buffer overflow."?

Only warns for the "known cases". So this would be one case:

```C
char buffer[5];
strcpy(buffer, "Too long of a string");
```

Everything is known at compile time, the compiler can generate a proper warning.

[MastaG]

Only warns for the "known cases". So this would be one case:

```C
char buffer[5];
strcpy(buffer, "Too long of a string");
```

Everything is known at compile time, the compiler can generate a proper warning.

And for most/all other cases we need something like Rust?

[Ananace]

And for most/all other cases we need something like Rust?

You can do quite a lot with some static analysis tooling in regular C/C++ as well, but they're quite a bit more expensive tasks compared to Rust, since the C language isn't as strict in tracking everything.

[archkde]

You can do quite a lot with some static analysis tooling in regular C/C++ as well, but they're quite a bit more expensive tasks compared to Rust, since the C language isn't as strict in tracking everything.

Rust slice length checking is not static analysis, it happens at runtime.

[Vorpal]

Rust slice length checking is not static analysis, it happens at runtime.

Yes, though the compiler will sometimes optimise it if it can figure it out.

In general it is proven to be impossible to statically determine non-trivial properties about programs in Turing complete languages though (see https://en.m.wikipedia.org/wiki/Rice's_theorem). Non-trivial here means any semantic property that isn't true/false for all programs in the given language.

What compilers and static analysis tools actually do is to answer these impossible yes/no problems with yes/no/maybe instead. Then you can treat the "maybe" as either "yes" or "no" depending on which is the safer option.

[kylew77]

Only warns for the "known cases". So this would be one case:

```C
char buffer[5];
strcpy(buffer, "Too long of a string");
```

Everything is known at compile time, the compiler can generate a proper warning.

Thanks makes perfect sense. It is like writing to an array[99] when an int array[5] is declared.

[archkde]

Yes, though the compiler will sometimes optimise it if it can figure it out.

In general it is proven to be impossible to statically determine non-trivial properties about programs in Turing complete languages though (see https://en.m.wikipedia.org/wiki/Rice's_theorem). Non-trivial here means any semantic property that isn't true/false for all programs in the given language.

What compilers and static analysis tools actually do is to answer these impossible yes/no problems with yes/no/maybe instead. Then you can treat the "maybe" as either "yes" or "no" depending on which is the safer option.

My point is that Rust does not improve the static analysis story over C/C++ here, which the comment I replied to can be interpreted as. C and C++ compilers will optimize manually written bounds checks away just as well as rustc does for the automatic one.

[NobodyXu]

My point is that Rust does not improve the static analysis story over C/C++ here, which the comment I replied to can be interpreted as. C and C++ compilers will optimize manually written bounds checks away just as well as rustc does for the automatic one.

Well lifetime and borrow checker is indeed an improvement to static analysis, rustc is able to apply no_alias attribute which is a feature rarely used by llvm C/C++ compiler that rustc discovers several bug in LLVM relating to no_alias