diff options
| author | Jiahao Li <jiahaoli@fb.com> | 2018-08-24 17:35:32 +0000 |
|---|---|---|
| committer | Akim Demaille <akim.demaille@gmail.com> | 2018-08-25 07:25:05 +0200 |
| commit | c1cf82f9c8ae92bb338f68d01033fef48a68d045 (patch) | |
| tree | 94a3c35ec6e4a4e1cbc664145b23f7a337e5b62a /data/variant.hh | |
| parent | 55947367c606fa1995c11c12f80d50a27ea28d0a (diff) | |
| download | bison-c1cf82f9c8ae92bb338f68d01033fef48a68d045.tar.gz | |
variant: fix uninitialized memory access in `variant<>`
Currently, in bison's C++ parser template (`lalr.cc`), the `variant<>`
struct's `build()` method uses placement-new in the form `new (...) T`
to initialize a variant type. However, for POD variant types, this
will leave the memory space uninitialized. If we subsequently tries
to `::move` into a variant object in such state, the call can trigger
clang's undefined behavior sanitizer due to accessing the
uninitialized memory.
https://lists.gnu.org/archive/html/bison-patches/2018-08/msg00098.html
* data/variant.hh (build): Always initialize the stored value.
Signed-off-by: Akim Demaille <akim@lrde.epita.fr>
Diffstat (limited to 'data/variant.hh')
| -rw-r--r-- | data/variant.hh | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/data/variant.hh b/data/variant.hh index 1ffc5b26..8d0f06f6 100644 --- a/data/variant.hh +++ b/data/variant.hh @@ -122,7 +122,7 @@ m4_define([b4_variant_define], YYASSERT (!yytypeid_); YYASSERT (sizeof (T) <= S); yytypeid_ = & typeid (T);])[ - return *new (yyas_<T> ()) T; + return *new (yyas_<T> ()) T (); } /// Instantiate a \a T in here from \a t. |