That is interesting to know, thank you. I have assumed that the tests being discussed were run-time tests.
Do the compile time tests work correctly even for cross-compiled systems, where there may be different capabilities (say, different sizes for cells) from the host?
I did not suggest that tests should be omitted - I suggested that compile-time checks are useful in addition to run-time tests. And I still think that the kind of automatic compile-time checking that is possible with a language like C is better than having to manually write tests in Forth - quite simply, you need to write fewer test cases if the toolchain can check more things automatically.
Yes.
(As a technicality, the IDE might do this sort of thing by running a program like cppcheck in the background, but it appears the same to the user.)
I understand that fine. And in a lot of C programming, it is a big pain that the language does not specify the size of an int - thus size-specific types are used (standardised in C99, but used long before that). So with C you have the choice to use efficient integers whose size depends on the target, or integers whose size is known and fixed.
msp430 and AVR (the AVR is 8-bit, but C "ints" and Forth cells are 16-bit).
It looks like the answer is simply that Forth does not support convenient portable programming across different cell sizes in code where you need to be accurate about your data sizes. It is /possible/ (see Gerry's answers), but ugly and inconvenient.
OK, that is an answer. It is not the only language with limitations like that.
(It is quite possible that particular implementations of Forth, targeted specifically for embedded systems and cross-compilation, have extensions or additional word sets designed to make it easy to get exact sized types, to access memory in specific sized units, etc.)