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 <robo...@celest.fr>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
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
