Not such a big deal in embedded, where the compiler and hardware is always the same, which means that the behavior is still predictable even if undefined

This is not true. Undefined behaviour can mean that

``` bool b; if (b) printf("1 "); if (!b) printf("2 "); ```

might print `1 2 `.

Right on. Unless the compiler documentation promises a consistent handling of the various triggers of undefined behaviour, it is under no obligation to always generate code that handles UB consistently.

To my knowledge there is no C compiler that promises to always handle all forms of UB consistently. The closest you could get would probably be something like Valgrind.

At least for this specific case Microsoft and Google are fixing it by always initializing the variables.

It's not like that is hard to fix, and modern compilers will flag uninitialized variables.

Use your brain and use your tools. C is not really that hard for a large number of problem sets.

Yet, CVE database is full of well known companies that apparently lack such developers.

If their salaries cannot find them, where are they?

Do we have a candidate to prove their secure reports as being wrong?

> It's not like that is hard to fix

In an embedded context, such bugs may be extremely costly to fix, if it's even possible.

> modern compilers will flag uninitialized variables

Reading uninitialized variables is one of the more easily prevented forms of undefined behaviour. As pjmlp points out, undefined behaviour in C/C++ programs is one of the major sources of security vulnerabilities in today's software.