Re: [Tinycc-devel] Zeroing stack variables CValue

[Domingo Alvarez Duarte]

Not only vtop, tok, tokc, error message was one of the bigs as well, with this first attempt I've tried to keep the name of variable and line numbers in a way that is more or less easy to compare before and after code refactoring.

After doing it I realize that a better design should be done, like trapping error and warning messages to user defined function, prefix global functions, structures to avoid name clashes with third party libraries/code, a better connection between code generation specific for each platform, ...

As I said this was a first attempt and is somehow working, now the community have one start point to decide and compare the pros & cons of a such code change.

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