Hi,
On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:
It's simple remove the zeroing CValues and try "make clean", "make" and
"make test" you'll see that on linux 32 bits and linux 64 bits and you'll
I see no errors on x86_64, I do see these errors on i386:
--------------
-Test C99 VLA 5 (bounds checking (might be disabled)): PASSED PASSED
PASSED PASSED PASSED PASSED PASSED PASSED
+Test C99 VLA 5 (bounds checking (might be disabled)): FAILED PASSED
FAILED PASSED FAILED PASSED FAILED PASSED
...
-I.. -I../include -b -run tcctest.c > test.out3
Runtime error: bad pointer in strlen()
at 0xf74e7f60 __bound_strlen()
../libtcc.c:255: by 0xf74dd261 tcc_strdup() (included from ../tcc.c)
--------------
Everything else works.
I see these error right before your commit 4bc83ac39 (CValue clearing),
and also with that commit, so for me it's not fixing anything. So, again,
please give us a testcase for the suspected bug you're trying to fix.
And I did not create that code I only found it as is an the bug pointed
Yes, it's pre-existing code, and yes, it _may_ contain a bug somewhere.
If there's a bug then it is accessing the wrong union member. Up to now
the bug hasn't been found.
and found this solution to be a good programming pratice.
Well, not if it merely hides a real bug that therefore then goes unfixed.
Now again can you explain me why zeroing CValues will produce incorrect
results on big-endian platforms, I didn't found this anywhere !
Sure, easy. Given:
union { int i; long long l;} u;
(assume 32bit int and 64bit long long)
Setting u.i=1 on little endian will make reading out u.l come out as 1 as
well. On big endian setting u.i will have set the _high_ 32 bit of u.l,
and hence reading out u.l will come out as 1LL<<32. You simply can't
transfer values via different-sized members of unions. That's why the
real bug must be found and fixed.
Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel