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

2022-07-19 Thread Christian JULLIEN 
-DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o x86_64-gen.o -c x86_64-gen.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o x86_64-link.o -c x86_64-link.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o i386-asm.o -c i386-asm.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -o tccmacho.o -c tccmacho.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.>> tcc -ar rcs libtcc.a libtcc.o tccpp.o tccgen.o tccdbg.o tccelf.o tccasm.o tccrun.o x86_64-gen.o x86_64-link.o i386-asm.o tccmacho.o>> tcc -o tcc tcc.o libtcc.a -lm -lpthread -ldl -arch x86_64>> ../tcc -c libtcc1.c -o libtcc1.o -B.. -I..>> ../tcc -c alloca.S -o alloca.o -B.. -I..>> ../tcc -c alloca-bt.S -o alloca-bt.o -B.. -I..>> ../tcc -c tcov.c -o tcov.o -B.. -I..>> ../tcc -c stdatomic.c -o stdatomic.o -B.. -I..>> ../tcc -c va_list.c -o va_list.o -B.. -I..>> ../tcc -ar rcs ../libtcc1.a libtcc1.o alloca.o alloca-bt.o tcov.o stdatomic.o va_list.o>> perl ./texi2pod.pl tcc-doc.texi tcc-doc.pod>> pod2man --section=1 --center="Tiny C Compiler" --release="0.9.27" tcc-doc.pod >tcc.1 && rm -f tcc-doc.pod>>  hello-exe >> Hello World>>  hello-run >> Hello World>>  libtest >> Hello World!>> fib(32) = 2178309>> add(32, 64) = 96>>  libtest_mt >> running fib with mixed calls>> 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946>> (15 ms)>> running fib in threads>> 1 2 8 3 5 21 144 89 610 55 987 13 1597 233 4181 2584 10946 6765 377 34>> (12 ms)>> running tcc.c in threads to run fib>> 1 987 233 21 8 89 3 144 13 1597 55 5 2 2584 610 10946 4181 377 34 6765>> (1014 ms)>> compiling tcc.c 10 times>> 1 2 3 4 5 6 7 8 9 10>> (492 ms)>> /bin/sh: line 1: 32935 Segmentation fault: 11./tcctest.gcc > test.ref>> make[2]: *** [test.ref] Error 139>> make[2]: Target `test3' not remade because of errors.>>>>> *Le : *16 juillet 2022 à 00:47 (GMT +02:00)> *De : *"grischka" > *À : *"tinycc-devel@nongnu.org" > *Objet : *Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks>>> On 13.07.2022 16:45, Ziyao wrote:>  > On Wed, Jul 13, 2022 at 12:01:57PM +0200, grischka wrote:>  >> Is it necessary or a good idea to remove that behavior/feature now>  >> from tcc?>  >> I've seen no arguments.>  >>  > Sorry for my impulsive decision.>  >>  > It is a valuable feature to be honest but supposed to be described>  > in document I think.>> To be honest, I don't know how valuable it is, or whether or not it> might be in use by someone out there. It could be useful maybe> with libtcc applications to wrap C-code in strings, for example.>>  > As for me, I agree with Vincent and am wishing to make TinyCC throw a>  > warning in this case at least,because it seems exactly to break the>  > language rules.>> Users, as we know, are fully entitled to express their wishes freely> as well as to call a bug whatever gets in their way and not to be> bothered with the details.>> But: As soon as someone considers to patch the public TinyCC, he> cannot see himself as an user merely anymore. He is expected to> know what he is doing and to have understood what has been done> before. (The short answer to a "Sometimes Asked Question")>> See also:> https://repo.or.cz/tinycc.git/commitdiff/af1abf1f45d45b34f0b02437f559f4dfdba7d23c>> -- grischka>>  >>  > Ziyao>> ___> Tinycc-devel mailing list> Tinycc-devel@nongnu.org> https://lists.nongnu.org/mailman/listinfo/tinycc-devel>>>> ___> Tinycc-devel mailing list> Tinycc-devel@nongnu.org> https://lists.nongnu.org/mailman/listinfo/tinycc-devel>___Tinycc-devel mailing listTinycc-devel@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/tinycc-devel

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-19 Thread grischka 
Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o tccmacho.o -c tccmacho.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -ar rcs libtcc.a libtcc.o tccpp.o tccgen.o tccdbg.o tccelf.o tccasm.o 
tccrun.o x86_64-gen.o x86_64-link.o i386-asm.o tccmacho.o

tcc -o tcc tcc.o libtcc.a -lm -lpthread -ldl -arch x86_64

../tcc -c libtcc1.c -o libtcc1.o -B.. -I..

../tcc -c alloca.S -o alloca.o -B.. -I..

../tcc -c alloca-bt.S -o alloca-bt.o -B.. -I..

../tcc -c tcov.c -o tcov.o -B.. -I..

../tcc -c stdatomic.c -o stdatomic.o -B.. -I..

../tcc -c va_list.c -o va_list.o -B.. -I..

../tcc -ar rcs ../libtcc1.a libtcc1.o alloca.o alloca-bt.o tcov.o stdatomic.o 
va_list.o

perl ./texi2pod.pl tcc-doc.texi tcc-doc.pod

pod2man --section=1 --center="Tiny C Compiler" --release="0.9.27" tcc-doc.pod >tcc.1 
&& rm -f tcc-doc.pod

 hello-exe 

Hello World

 hello-run 

Hello World

 libtest 

Hello World!

fib(32) = 2178309

add(32, 64) = 96

 libtest_mt 

running fib with mixed calls

1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946

(15 ms)

running fib in threads

1 2 8 3 5 21 144 89 610 55 987 13 1597 233 4181 2584 10946 6765 377 34

(12 ms)

running tcc.c in threads to run fib

1 987 233 21 8 89 3 144 13 1597 55 5 2 2584 610 10946 4181 377 34 6765

(1014 ms)

compiling tcc.c 10 times

1 2 3 4 5 6 7 8 9 10

(492 ms)

/bin/sh: line 1: 32935 Segmentation fault: 11./tcctest.gcc > test.ref

make[2]: *** [test.ref] Error 139

make[2]: Target `test3' not remade because of errors.




*Le : *16 juillet 2022 à 00:47 (GMT +02:00)
*De : *"grischka" 
*À : *"tinycc-devel@nongnu.org" 
*Objet : *Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 
blocks


On 13.07.2022 16:45, Ziyao wrote:
 > On Wed, Jul 13, 2022 at 12:01:57PM +0200, grischka wrote:
 >> Is it necessary or a good idea to remove that behavior/feature now
 >> from tcc?
 >> I've seen no arguments.
 >
 > Sorry for my impulsive decision.
 >
 > It is a valuable feature to be honest but supposed to be described
 > in document I think.

To be honest, I don't know how valuable it is, or whether or not it
might be in use by someone out there. It could be useful maybe
with libtcc applications to wrap C-code in strings, for example.

 > As for me, I agree with Vincent and am wishing to make TinyCC throw a
 > warning in this case at least,because it seems exactly to break the
 > language rules.

Users, as we know, are fully entitled to express their wishes freely
as well as to call a bug whatever gets in their way and not to be
bothered with the details.

But: As soon as someone considers to patch the public TinyCC, he
cannot see himself as an user merely anymore. He is expected to
know what he is doing and to have understood what has been done
before. (The short answer to a "Sometimes Asked Question")

See also:

https://repo.or.cz/tinycc.git/commitdiff/af1abf1f45d45b34f0b02437f559f4dfdba7d23c

-- grischka

 >
 > Ziyao

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-16 Thread Christian JULLIEN 


Hi, with mod (having your last commit),I get this error on macOS:/bin/sh: line 1: 32935 Segmentation fault: 11  ./tcctest.gcc > test.ref./configure --cpu=x86_64 --config-bcheck=no --config-backtrace=no --cc=tcc --prefix=/Users/jullien/tinycc/static=== /Users/jullien/local-tcc/bin/tccBinary directory    /Users/jullien/tinycc/static/binTinyCC directory    /Users/jullien/tinycc/static/lib/tccLibrary directory   /Users/jullien/tinycc/static/libInclude directory   /Users/jullien/tinycc/static/includeManual directory    /Users/jullien/tinycc/static/share/manInfo directory      /Users/jullien/tinycc/static/share/infoDoc directory       /Users/jullien/tinycc/static/share/doc/usr/include dir    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/includeSource path         /Users/jullien/tinyccC compiler          tcc (0.927)Target OS           DarwinCPU                 x86_64Config              OSX dll=no bcheck=no backtrace=noCreating config.mak and config.htcc -o tcc.o -c tcc.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -DTCC_GITHASH="\"mob:af1abf1\"" -Wall -O2 -arch x86_64 -I. tcc -o libtcc.o -c libtcc.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -DC2STR conftest.c -o c2str.exe && ./c2str.exe include/tccdefs.h tccdefs_.htcc -o tccpp.o -c tccpp.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccgen.o -c tccgen.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccdbg.o -c tccdbg.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccelf.o -c tccelf.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccasm.o -c tccasm.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccrun.o -c tccrun.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o x86_64-gen.o -c x86_64-gen.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o x86_64-link.o -c x86_64-link.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o i386-asm.o -c i386-asm.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -o tccmacho.o -c tccmacho.c -DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\"" -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0       -DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I. tcc -ar rcs libtcc.a libtcc.o tccpp.o tccgen.o tccdbg.o tccelf.o tccasm.o tccrun.o x86_64-gen.o x86_64-link.o i386-asm.o tccmacho.otcc -o tcc tcc.o libtcc.a -lm -lpthread -ldl -arch x86_64 ../tcc -c libtcc1.c -o libtcc1.o -B.. -I/tcc -c alloca.S -o alloca.o -B.. -I/tcc -c alloca-bt.S -o alloca-bt.

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

2022-07-15 Thread grischka 

On 13.07.2022 16:45, Ziyao wrote:

On Wed, Jul 13, 2022 at 12:01:57PM +0200, grischka wrote:

Is it necessary or a good idea to remove that behavior/feature now
from tcc?
I've seen no arguments.


Sorry for my impulsive decision.

It is a valuable feature to be honest but supposed to be described
in document I think.


To be honest, I don't know how valuable it is, or whether or not it
might be in use by someone out there.  It could be useful maybe
with libtcc applications to wrap C-code in strings, for example.


As for me, I agree with Vincent and am wishing to make TinyCC throw a
warning in this case at least,because it seems exactly to break the
language rules.


Users, as we know, are fully entitled to express their wishes freely
as well as to call a bug whatever gets in their way and not to be
bothered with the details.

But:  As soon as someone considers to patch the public TinyCC, he
cannot see himself as an user merely anymore.  He is expected to
know what he is doing and to have understood what has been done
before. (The short answer to a "Sometimes Asked Question")

See also:
https://repo.or.cz/tinycc.git/commitdiff/af1abf1f45d45b34f0b02437f559f4dfdba7d23c

-- grischka



Ziyao


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-13 Thread Vincent Lefevre 
On 2022-07-13 20:12:25 +0200, grischka wrote:
> 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.

Well, in the tcc manual, there seems to be an intent to support C99:

  TCC implements many features of the new C standard: ISO C99.  Currently
  missing items are: complex and imaginary numbers.

The absence of required diagnostics is not a missing item.

And note that this is not listed as an extension either.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

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

2022-07-13 Thread grischka 

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

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

2022-07-13 Thread Vincent Lefevre 
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.

> 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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

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

2022-07-13 Thread Ziyao 
On Wed, Jul 13, 2022 at 12:01:57PM +0200, grischka wrote:
> Is it necessary or a good idea to remove that behavior/feature now
> from tcc?
> I've seen no arguments.

Sorry for my impulsive decision.

It is a valuable feature to be honest but supposed to be described
in document I think.

As for me,I agree with Vincent and am wishing to make TinyCC throw a
warning in this case at least,because it seems exactly to break the
language rules.

Maybe we could revert this commit,keep this feature but make TinyCC
print a message when -Wall option is specified.

Ziyao


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-13 Thread grischka 

On 13.07.2022 09:35, Ziyao wrote:


 "Fix wrong handling of strings which do not end properly at the end of line"


I think this conclusion is just as wrong as the initial assumption made
in the thread subject "Bug that TinyCC Analyses Strings inside #if 0 blocks".

There was no bug here in tcc,  it was/is just different behavior, fully
intentional and even documented with a test case.

(actually the behavior is as in gcc-2.95.3 which IIRC as the final release
of the 2.xx line was very good and quasi state-of-the-art at the time when
tcc was written first.)

Is it necessary or a good idea to remove that behavior/feature now from tcc?
I've seen no arguments.

--- grischka



Ziyao

---

diff --git a/tccpp.c b/tccpp.c
index 25654b2..f070640 100644
--- a/tccpp.c
+++ b/tccpp.c
@@ -944,19 +944,16 @@ static uint8_t *parse_pp_string(uint8_t *p,
  }
  }
  } else if (c == '\n') {
-file->line_num++;
-goto add_char;
+tcc_error("missing terminating %c character",sep);
  } else if (c == '\r') {
  PEEKC_EOB(c, p);
  if (c != '\n') {
  if (str)
  cstr_ccat(str, '\r');
  } else {
-file->line_num++;
-goto add_char;
+tcc_error("missing terminating %c character",sep);
  }
  } else {
-add_char:
  if (str)
  cstr_ccat(str, c);
  p++;
diff --git a/tests/tcctest.c b/tests/tcctest.c
index e969c76..f7fbd65 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -4253,11 +4253,6 @@ void func_arg_test(void)
  /* gcc 2.95.3 does not handle correctly CR in strings or after strays */
  #define CORRECT_CR_HANDLING

-/* deprecated and no longer supported in gcc 3.3 */
-#ifdef __TINYC__
-# define ACCEPT_CR_IN_STRINGS
-#endif
-
  /* keep this as the last test because GCC messes up line-numbers
 with the ^L^K^M characters below */
  void whitespace_test(void)
@@ -4279,20 +4274,6 @@ ntf("aaa=%d\n", 3);
  \
  ntf("min=%d\n", 4);

-#ifdef ACCEPT_CR_IN_STRINGS
-printf("len1=%d\n", strlen("
-"));
-#ifdef CORRECT_CR_HANDLING
-str = "
-";
-printf("len1=%d str[0]=%d\n", strlen(str), str[0]);
-#endif
-printf("len1=%d\n", strlen("
a
-"));
-#else
-printf("len1=1\nlen1=1 str[0]=10\nlen1=3\n");
-#endif /* ACCEPT_CR_IN_STRINGS */
-
  #ifdef __LINE__
  printf("__LINE__ defined\n");
  #endif


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-13 Thread Ziyao 
On Tue, Jul 12, 2022 at 03:17:09PM +0200, Vincent Lefevre wrote:
> 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.

I have made a simple patch and pushed it towards the git repository.
It will throw an error if there is no terminating character of a string at
the end of line.A part of tcctest3 related to this issue is deleted.

Ziyao

---

diff --git a/tccpp.c b/tccpp.c
index 25654b2..f070640 100644
--- a/tccpp.c
+++ b/tccpp.c
@@ -944,19 +944,16 @@ static uint8_t *parse_pp_string(uint8_t *p,
 }
 }
 } else if (c == '\n') {
-file->line_num++;
-goto add_char;
+tcc_error("missing terminating %c character",sep);
 } else if (c == '\r') {
 PEEKC_EOB(c, p);
 if (c != '\n') {
 if (str)
 cstr_ccat(str, '\r');
 } else {
-file->line_num++;
-goto add_char;
+tcc_error("missing terminating %c character",sep);
 }
 } else {
-add_char:
 if (str)
 cstr_ccat(str, c);
 p++;
diff --git a/tests/tcctest.c b/tests/tcctest.c
index e969c76..f7fbd65 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -4253,11 +4253,6 @@ void func_arg_test(void)
 /* gcc 2.95.3 does not handle correctly CR in strings or after strays */
 #define CORRECT_CR_HANDLING
 
-/* deprecated and no longer supported in gcc 3.3 */
-#ifdef __TINYC__
-# define ACCEPT_CR_IN_STRINGS
-#endif
-
 /* keep this as the last test because GCC messes up line-numbers
with the ^L^K^M characters below */
 void whitespace_test(void)
@@ -4279,20 +4274,6 @@ ntf("aaa=%d\n", 3);
 \
 ntf("min=%d\n", 4);
 
-#ifdef ACCEPT_CR_IN_STRINGS
-printf("len1=%d\n", strlen("
-"));
-#ifdef CORRECT_CR_HANDLING
-str = "
-";
-printf("len1=%d str[0]=%d\n", strlen(str), str[0]);
-#endif
-printf("len1=%d\n", strlen("
a
-"));
-#else
-printf("len1=1\nlen1=1 str[0]=10\nlen1=3\n");
-#endif /* ACCEPT_CR_IN_STRINGS */
-
 #ifdef __LINE__
 printf("__LINE__ defined\n");
 #endif


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-12 Thread Vincent Lefevre 
On 2022-07-11 21:57:45 +0800, Ziyao wrote:
> The simpliest example is like below:
> 
> #if 0
> "
> #if 0
> "
> #endif
> #endif

Going back to this example, even if GCC doesn't give an error,
consider a slight variation:

#if 0
R"-(
#if 0
)-"
#endif
#endif

This time, one gets an error with gcc (default GNU dialect or C++):

err.c:6:2: error: #endif without #if
6 | #endif
  |  ^

And the following code

#if 0
R"-(
#if 0
)-"
#endif

does not give any warning or error (the behavior is different
if one provides an option like -std=c99 to follow ISO C99).

This is due to the use of a "raw string literal", specified
by C++11 (and this can also be regarded as a C extension),
which allows newline characters.

This shows that you cannot ignore parsing in a skipped block.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

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

2022-07-12 Thread 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 

#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  - Web: 
100% accessible validated (X)HTML - 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

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

2022-07-11 Thread Vincent Lefevre 
On 2022-07-12 10:31:26 +0800, Ziyao wrote:
> - Original Message - 
> From: "Vincent Lefevre" 
> To: tinycc-devel@nongnu.org
> Sent: Tue, 12 Jul 2022 02:44:50 +0200
> Subject: Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 
> blocks
> >  That's why I said that there should be
> > a diagnostic. So the missing diagnostic with tcc is a bug.
> > If the program is not rejected, the behavior is undefined.
> 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.

> 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.

-- 
Vincent Lefèvre  - 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

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

2022-07-11 Thread Ziyao 
- Original Message - 
From: "Vincent Lefevre" 
To: tinycc-devel@nongnu.org
Sent: Tue, 12 Jul 2022 02:44:50 +0200
Subject: Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks
>  That's why I said that there should be
> a diagnostic. So the missing diagnostic with tcc is a bug.
> If the program is not rejected, the behavior is undefined.
So is it better to throw an error and then stop 
compiling here like gcc?Or just print a warning?


I am going to make a patch for this


Ziyao___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-11 Thread Vincent Lefevre 
On 2022-07-12 06:57:41 +0800, Ziyao wrote:
> On Mon, Jul 11, 2022 at 05:47:31PM +0200, Domingo Alvarez Duarte wrote:
> > Hello Ziyao !
> > 
> > Although gcc compiles a file containing your example with warnings, I'm not
> > sure it's worth try to do the same in TiinyCC the preprocessor probably uses
> > TOKENS from the lexer to decide to skip till the end of the initial "#if 0"
> > and '"' is not a valid token the error probably come from the lexer that
> > found a non terminated string.
> > 
> For conditional inclusion,C99 document says:
>   Only the first group whose control condition evaluates to true
>   (nonzero) is processed. If none of the conditions evaluates to true,
>   and there is a #else directive, the group controlled by the #else is
>   processed; lacking a #else directive, all the groups until the
>   #endif are skipped.1
> In my understanding,the skipped part should NOT be processed.

To be able to skip it, the compiler needs to parse it as described
in 6.10. So code like

#if 0
#if 1
#else
foo
#endif
#else
OK
#endif

should give OK. And if anything violates the syntax during parsing,
one should get a diagnostic.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

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

2022-07-11 Thread Vincent Lefevre 
On 2022-07-12 06:56:34 +0800, Ziyao wrote:
> > while with tcc:
> > 
> > zira:~> tcc -E err.c
> > # 1 "err.c"
> > # 1 "" 1
> > # 2 "err.c" 2
> > 
> > 
> > "
> > FOO
> > "
> > "FOO"
> > 
> > which makes more sense as an extension, IMHO. But tcc doesn't give
> > any diagnostic there, and I think that this is incorrect.
> 
> It seems that TinyCC parses the first three lines as a string
> literature,does't it?

Yes, tcc ends the string literal only at a terminating " character
and seems to accept anything before it. This can be seen on

#define FOO bar
"
FOO

which gives an error

  err.c:4: error: missing terminating " character

at line 4.

> But according to C99 standard,
> 
> string-literal:
>   " s-char-sequenceopt "
>   L" s-char-sequenceopt "
> s-char-sequence:
>   s-char
>   s-char-sequence s-char
> s-char:
>   any member of the source character set except the double-quote ",
>   backslash \, or new-line character
>   escape-sequence
> 
> New-line character cannot be included in a string literature.

For this reason, this violates a syntax rule, and the C standard
says "A conforming implementation shall produce at least one
diagnostic message [...] if a preprocessing translation unit
or translation unit contains a violation of any syntax rule
or constraint [...]". That's why I said that there should be
a diagnostic. So the missing diagnostic with tcc is a bug.

If the program is not rejected, the behavior is undefined.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

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

2022-07-11 Thread Ziyao 
On Mon, Jul 11, 2022 at 05:47:31PM +0200, Domingo Alvarez Duarte wrote:
> Hello Ziyao !
> 
> Although gcc compiles a file containing your example with warnings, I'm not
> sure it's worth try to do the same in TiinyCC the preprocessor probably uses
> TOKENS from the lexer to decide to skip till the end of the initial "#if 0"
> and '"' is not a valid token the error probably come from the lexer that
> found a non terminated string.
> 
For conditional inclusion,C99 document says:
Only the first group whose control condition evaluates to true
(nonzero) is processed. If none of the conditions evaluates to true,
and there is a #else directive, the group controlled by the #else is
processed; lacking a #else directive, all the groups until the
#endif are skipped.1
In my understanding,the skipped part should NOT be processed.

Ziyao


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-11 Thread Ziyao 
> while with tcc:
> 
> zira:~> tcc -E err.c
> # 1 "err.c"
> # 1 "" 1
> # 2 "err.c" 2
> 
> 
> "
> FOO
> "
> "FOO"
> 
> which makes more sense as an extension, IMHO. But tcc doesn't give
> any diagnostic there, and I think that this is incorrect.

It seems that TinyCC parses the first three lines as a string
literature,does't it?

But according to C99 standard,

string-literal:
" s-char-sequenceopt "
L" s-char-sequenceopt "
s-char-sequence:
s-char
s-char-sequence s-char
s-char:
any member of the source character set except the double-quote ",
backslash \, or new-line character
escape-sequence

New-line character cannot be included in a string literature.

Ziyao


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

2022-07-11 Thread Vincent Lefevre 
On 2022-07-11 17:47:31 +0200, Domingo Alvarez Duarte wrote:
> Although gcc compiles a file containing your example with warnings, I'm not
> sure it's worth try to do the same in TiinyCC the preprocessor probably uses
> TOKENS from the lexer to decide to skip till the end of the initial "#if 0"
> and '"' is not a valid token the error probably come from the lexer that
> found a non terminated string.

I agree that tcc should reject the code. It is too ambiguous to be
regarded as an extension. GCC's interpretation is rather ugly.

Consider a file "err.c":

#define FOO bar
"
FOO
"
"FOO"

zira:~> gcc -E err.c 2> /dev/null
# 0 "err.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "err.c"

"
bar
"
"FOO"

while with tcc:

zira:~> tcc -E err.c
# 1 "err.c"
# 1 "" 1
# 2 "err.c" 2


"
FOO
"
"FOO"

which makes more sense as an extension, IMHO. But tcc doesn't give
any diagnostic there, and I think that this is incorrect.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

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

2022-07-11 Thread Domingo Alvarez Duarte 

Hello Ziyao !

Although gcc compiles a file containing your example with warnings, I'm 
not sure it's worth try to do the same in TiinyCC the preprocessor 
probably uses TOKENS from the lexer to decide to skip till the end of 
the initial "#if 0" and '"' is not a valid token the error probably come 
from the lexer that found a non terminated string.


Cheers !

On 11/7/22 15:57, Ziyao wrote:

Hi list,

When I was compiling Bash with TinyCC,an error occurred.

The simpliest example is like below:

#if 0
"
#if 0
"
#endif
#endif

Code within #if 0 ... end block should be ignored.But this code breaks
TinyCC.TinyCC seems to analyse the string inside the useless code block.

As many use #if 0 blocks as comments,maybe this is valuable to fix.

Tons of thanks for your help

Ziyao


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel