Re: [Tinycc-devel] Zeroing stack variables CValue

[Domingo Alvarez Duarte]

Thanks a lot for your explanation of unions on big endian, with that in mind I can see now that we have a bigger problem that what I thought at first, the problem that you explained seem to not been taken in account in several places in tinycc.

How do you propose to solve this specific problem ?

----

ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v)
{
    CValue cval;
    memset(&cval, 0, sizeof(CValue));

    cval.i = v; //,<<<<<<<<<<< here is the main bug that mix with garbage
    vsetc(tcc_state, type, r, &cval);
}

----

----

/* store a value or an _expression_ directly in global data or in local array */
static void init_putv(TCCState* tcc_state, CType *type, Section *sec, unsigned long c,
                      int v, int expr_type)
{
...
        case VT_PTR:
            if (tcc_state->tccgen_vtop->r & VT_SYM) {
                greloc(tcc_state, sec, tcc_state->tccgen_vtop->sym, c, R_DATA_PTR);
            }

//<<< on the next line is where we try to get the assigned value to cvalue.i as cvalue.ull
            *(addr_t *)ptr |= (tcc_state->tccgen_vtop->c.ull & bit_mask) << bit_pos;
            break;

----

On Sat, Mar 29, 2014 at 5:20 PM, Michael Matz <address@hidden> wrote:

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel