Interpret integer values as BOOL for condition checks

[mhasel]

I think it would be sensible to allow integer values to be used in conditions in order to support C interop (e.g. exit codes, null-pointer checks).

It might be enough to just configure the severity of the diagnostics we have in place already, but on the other hand we should still throw hard-errors if the conditions contain any other type than BOOL or integers, so splitting them into separate diagnostics might be necessary.
All in all I am not sure how common it is to directly check function exit codes in statements in PLC programming, but I feel like using the read function from <unistd.h> or similar examples like this:

WHILE read(file_descriptor, buffer, bytes_to_read) DO END_WHILE;

to read to the end of a file might not be too far-fetched.

Edit: Related PRs #1129 & #1140

[volsa]

Assuming we do end up supporting this, do we interpret a (signed) integer value of 0 as false and everything else as true?

Edit: Played with some C code, everything other than 0 is interpreted as true

[volsa]

I guess this needs some further discussion in the team. For what it's worth, an internal project makes use of integers in control statements (if, while) yielding a lot of "Expected a boolean, got DINT" errors. CodeSys doesn't allow this either (only allowing booleans), expect when it's a constant 0 or 1 value. So the question is, do we

• mimick CodeSys (theoretically also how the standard defines it)
• loosen up the standard severity of this to a warning (for numerical values only) or
• leave it to the user, allowing them to change the severity to a warning / info (though the compiler will panic if anything other than a numerical value is passed)