Re: [Tinycc-devel] Zeroing stack variables CValue

[Domingo Alvarez Duarte]

When I found this problem and looked at how CValue is defined I saw a potential for later new field been added changed and then I decided to always start with generic well known state (everything zeroed) otherwise bugs like this one that can manifest randomly depending on the garbage at the execution time, also any usage of unitialized structs/vars can potentially be the source of hard to find bugs.

So I do not see your suggestion as a good replacement for zeroing then before use, and I'm not aware about the difference it will make on little/big endian machines the fact that structures are zeroed. Are you sure about that ?

Cheers !

On Thu, Mar 27, 2014 at 3:44 PM, Thomas Preudhomme <address@hidden> wrote:

Le 2014-03-27 07:23, Domingo Alvarez Duarte a écrit :

Again my mistake, it does pass vla tests on linux 32 bits, the bounds
check tests fail with garbage being passed to strlen.
On arm it also works.

Hi Domingo,

I took a look at your patch and although I agree there is some problems, I find the approach a bit intrusive. For instance, in the vset case instead of zeroing the cval it would be better to fix the places that read the .ull field when it was initialized with vset. Normally a code would check the type before reading .ull and any caller of vset should do the right thing if the type needs to use the .ull field.

There is also get_tok_str that would require fixing as (as was pointed out by mobi phil) many caller of that function gives NULL as second parameter. It would be easily fixed with:

CValue cval;

if (!cv) {
    cval.ull = 0;
    cv = &cval;
}

The only place that should be fixed is when a variable is read but not initialized. When the wrong field of an union is read, either another field should be read or another field should have been set. Also, if tcc was used some day to compile on a big endian system the zeroing would also lead to garbage being read (only on little endian does it have no impact).

By the way, I'll try my best to take a look at your patch after the release. We'll then figure out how to best merge it. Maybe it's better in one big commit, I need to look at it first. I guess vtop, tok and tok are the biggest reason to have TCCState sneak in all function prototype, is that it?

Best regards,

Thomas

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