On 13.07.2022 17:17, Vincent Lefevre wrote:
On 2022-07-13 12:01:57 +0200, grischka wrote:
There was no bug here in tcc, it was/is just different behavior, fully
intentional and even documented with a test case.
There was a bug in tcc: the ISO C standard requires a diagnostic.
Well, define "bug" ...?
In my book, a bug is unwanted behavior in the sense of unwanted by
the person who wrote the code. It is when what I wrote (for example)
doesn't do what I want.
Common sources of bugs are, beyond simple mistakes, that (1) I maybe don't
really know what I want, or maybe that (2) I refuse to acknowledge that
what I want, in combination, is logically impossible.
It is not a bug, per se, when tcc doesn't work like gcc, or when it doesn't
conform to the standards in some aspect. As long the behavior is on purpose
and consistent. In my book.
Is it necessary or a good idea to remove that behavior/feature now from tcc?
I've seen no arguments.
Detect bugs in user code.
Which is a good thing per se, but see (2) above: It is logically not
possible to allow new-lines in strings and at the same time help the
user to find out that for example
"
#if 0
"
was not written by intention. Because in the logic of tcc's (admittedly
non-conformant) behavior, there is no bug. There is simply the string
"\n#if 0\n"
At which point one could discuss -Wstrict or -Wpedantic, or maybe to give
up on the non-conformant behavior (as already shown) at all, or to replace
it eventually by the new "raw string literals" that you mentioned (my
favorite).
--- grischka
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
