Michael Matz wrote:
Thanks. While it doesn't crash for me on x86-64 (with rev aa561d70,
i.e. before your memset patch) I do see the wrong vset flowing into
init_putv; it's unary(), case TOK_LAND, which does
vset(&s->type, VT_CONST | VT_SYM, 0);
vtop->sym = s;
Using
I even thought of using a static const initialized CValue and then when
declaring CValues on the stack do this:
CValue cv = ConstInitializedCValue;
But as you've pointed out it doesn't solve the real problem of setting one
member of the union and trying to get another meber of different size.
An
Not at all, now you also could see what I saw there and then decided for
the short path to see it working, probably you don't see the problem
because it's erratic depending on what exists on the stack at the function
call and for some reason on my machine it always have garbage there and
always the
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
Ok now I understand your point, here is the minimal program that I was using
to trace it:
int main() {
int x;
static void *label_return = &&lbl_return;
//printf("label_return = %p\n", label_return);
goto *label_return; //< here seg
Ok now I understand your point, here is the minimal program that I was
using to trace it:
int main() {
int x;
static void *label_return = &&lbl_return;
//printf("label_return = %p\n", label_return);
goto *label_return; //< here segfault on linux X86_64 without the
memset on vset
//printf(
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
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 m
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 ?
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 (b
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
see that it doesn't pass the tests, on linux 32 bits try "make test -i" and
you'll see garbage been generated.
And I did not create that code I only fou
Hi,
On Wed, 26 Mar 2014, Domingo Alvarez Duarte wrote:
On my commit
It would be easier if you wrote your reasons for doing things in mails,
not only in commit messages, it makes quoting much harder. Anyway, in the
commit message you wrote:
I found the problem it was because CValue sta
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 executi
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
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 t
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.
On Wed, Mar 26, 2014 at 8:30 PM, Domingo Alvarez Duarte
wrote:
> Hello !
>
> On my commit I posted that it solves the vla tests on linux 32bits, it wa
14 matches
Mail list logo
