[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Zeroing stack variables CValue

From: Michael Matz
Subject: Re: [Tinycc-devel] Zeroing stack variables CValue
Date: Sat, 29 Mar 2014 18:20:11 +0100 (CET)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]