Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

[Vincent Lefevre]

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 <vincent@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)