[Bug middle-end/105709] FORTIFY_SOURCE=3 (*** buffer overflow detected ***: terminated) on Qt

[siddhesh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709

--- Comment #9 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> ---
>From a quick check of non-reduced-qt.cxx, clang appears to fail to fortify the
readlink function, which may explain why you see the failure with gcc but not
clang.  Also the reduced reproducer in comment 1 looks wrong; it passes a 0
object size to __readlink_chk, which is guaranteed to fail.  The correct
reproducer in that context is:

```
extern "C" void __readlink_chk(char *, char *, long, long);
char readlink___path, readlink___buf;
namespace Qt {
enum Initialization {} Uninitialized;
}
struct QArrayData {
  int size;
};
struct QByteArray {
  QByteArray(int, Qt::Initialization);
  ~QByteArray();
  int size() const;
  QArrayData d;
};
QByteArray::~QByteArray() {}
int QByteArray::size() const { return d.size; }
main() {
  QByteArray buf(6, Qt::Uninitialized);
  int __trans_tmp_1 = buf.size();
  __readlink_chk(&readlink___path, &readlink___buf, __trans_tmp_1,
__builtin_dynamic_object_size (&readlink___buf, 0));
}
```

which again, is invalid code because the readlink is passed a 1 byte buffer and
read an uninitialized number of bytes, which again fails correctly.  Fun fact:
this code will likely *pass* if -ftrivial-auto-var-init is passed!  I guess one
can't win everything...

Now looking at the original code, it seems similar to the issue in bug 105078,
which is basically an attempt to use an implicit flex array (by overallocating
memory to the object) which is not guaranteed to work all the time.  Clang
simply bails out at some point, because of which it doesn't fortify the
readlink call and everything is good.