despite the warning

Here is what is wrong. Compiler tells you that one's better not to scanf to bools with %d, because it expects pointer to int. It does not matter whether it usually works or not — C++ is not like Python, there is no reference implementation, the only thing you can rely on is the standard. A lot of things are undefined behavior, i.e. they can behave as you can expect and they can behave differently on other machines. Moreover, if your program have at least one undefined behavior, its whole behavior is undefined as well — it can crash in a random place, it can produce wrong answer, it can wipe your HDD out (however, this usually does not happen).

To the details: %d expects pointer to integer, and scanf has no way to know that you've passed pointer to bool instead. I'll explain my understanding of why could it work, but remember — it's still undefined behavior, never rely on it!

As we have little-endian architecture, writing four bytes (like 0x01 0x00 0x00 0x00, and here I assume that int is four-bytes long) to bool variable works well as long as we're not spoiling memory which immediately follows this bool. For example, if you have an array of bools, it will just zero three consecutive elements, which is not a big deal, as they already were zeros. However, on big tests you reach end of the array and somewhat important can follow that array. You're overriding something and your program starts behaving strangely — very alike array overflow.

You may wonder why cin works well then. Answer is easy: cin is a C++ thing (in contrast with scanf which came from C), >> is an overloaded operator, which is defined for plenty of types, including bool, so it has a very good idea about types and can behave accordingly. If it wasn't defined for bool, you'd probably get compilation error or some strange behavior because of type casts (well-defined, however).

you could do something like this: scanf("%d",&tmp); t[i][j] = tmp;