On 2022-07-12 05:35:50 +0200, Vincent Lefevre wrote: > On 2022-07-12 10:31:26 +0800, Ziyao wrote: > > So is it better to throw an error and then stop > > compiling here like gcc? > > With GCC, this is an error only with -pedantic-errors or similar. > But there is at least a warning.
After more testing, without -pedantic-errors, a missing terminating " character becomes an error when compiling. It is a warning only at the preprocessor level. So, if the buggy code is in a skipped block (e.g., under "#if 0"), then this remains a warning since the code is skipped at the preprocessor level. But due to the possible confusion with a different way of parsing (as currently done by tcc), I think that an error would be better than a warning also at the preprocessor level. > > Or just print a warning? > > Since one cannot rely on portable behavior (the code is really > ambiguous, with no natural interpretation), I think that an error > would be better. > > I think that the fact that GCC just emits a warning is that it > assumes that in practice, the preprocessor will not be involved. > But it may be wrong and the result may be unexpected by the user. Since one gets an error at compile time, there must be another reason. Note also that #include <stdio.h> #define FOO "1 2" int main (void) { char *s = FOO; puts (s); return 0; } compiles without warnings or errors with tcc, and 1 2 is output by the generated program. First, this breaks the ISO C syntax rules, thus a diagnostic is required by the standard. Moreover, a multiline #define like that (without backslash + newline) is unintuitive. So I would say that the code should be rejected. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel