tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] [BUG] tcc and INT64: wrong result of comparison (a te


From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] [BUG] tcc and INT64: wrong result of comparison (a test included)
Date: Sun, 04 Jan 2015 16:51 +0000
User-agent: KMail/4.14.1 (Linux/2.6.38-ac2-ac100; KDE/4.14.2; armv7l; ; )

Le dimanche 4 janvier 2015, 19:18:34 Sergey Korshunoff a écrit :
> By replacing a -2147483648 with a -2147483647 I can succesfully build
> a working nim compiler. But this is not so good...

The bug is in tccpp.c parse_number. The function tries to guess what should be 
the size and sign of the litteral before parsing the suffix (which might not 
exist).

        /* XXX: not exactly ANSI compliant */
        if ((n & 0xffffffff00000000LL) != 0) {
            if ((n >> 63) != 0)
                tok = TOK_CULLONG;
            else
                tok = TOK_CLLONG;
        } else if (n > 0x7fffffff) {
            tok = TOK_CUINT;
        } else {
            tok = TOK_CINT;
        }

In your case it will pass in the first else if and set tok to TOK_CUINT. So far 
so good.

Then it will parse the suffix and when it sees the second L it does this:

                    if (tok == TOK_CINT)
                        tok = TOK_CLLONG;
                    else if (tok == TOK_CUINT)
                        tok = TOK_CULLONG;

So here it will set the value to TOK_CULLONG while it should set it to 
TOK_CLLONG and warn if the value is too big.

My feeling is that the automatic guess for the size and sign should be done 
after trying to look for a suffix.

The algorithm would be something like:

1) Set tok to TOK_CINT and suffix_found to false.
2) Then look for a L or U suffix with unchanged code except for setting a 
suffix_found variable if any such suffix is found.
3) Then if suffix_found is false try automatic detection, otherwise warn of 
overflow and possibly process the overflow (what does GCC does in this case?) 
Be 
careful about the sign when checking for overflow.

Do you want to take a stab at it?

Best regards,

Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]