* Re: [9front] cc: fix conversion of constants to match c99.
2022-05-05 13:18 [9front] cc: fix conversion of constants to match c99 ori
@ 2022-05-05 18:20 ` Michael Forney
0 siblings, 0 replies; 2+ messages in thread
From: Michael Forney @ 2022-05-05 18:20 UTC (permalink / raw)
To: 9front
On 2022-05-05, ori@eigenstate.org <ori@eigenstate.org> wrote:
> Earlier, I'd done a half-assed job of this, this patch corrects
> it and makes the code less ugly. (thanks to adr on 9fans)
Are there any constants in the 9front codebase that change their type
after this change? If so, which ones?
Maybe we could do a test build that has the old and new logic and
prints a diagnostic if anything changes type, then investigate any
results to see if it would introduce any bugs.
> ok to commit?
>
> diff 641bd4512ff02b1b86157263ab604bc790f0c89d uncommitted
> --- a/sys/src/cmd/cc/lex.c
> +++ b/sys/src/cmd/cc/lex.c
> @@ -444,7 +444,7 @@
> yylex(void)
> {
> vlong vv;
> - long c, c1, t, w;
> + long c, c1, t;
> char *cp;
> Rune rune;
> Sym *s;
> @@ -848,17 +848,11 @@
> yyerror("overflow in constant");
>
> vv = yylval.vval;
> - /*
> - * c99 is silly: decimal constants stay signed,
> - * hex and octal go unsigned before widening.
> - */
> - w = 32;
> - if((c1 & (Numdec|Numuns)) == Numdec)
> - w = 31;
> - if(c1 & Numvlong || (c1 & Numlong) == 0 && (uvlong)vv >= 1ULL<<w){
> - if((c1&(Numdec|Numvlong)) == Numdec && vv < 1ULL<<32)
> - warn(Z, "int constant widened to vlong: %s", symb);
> - if((c1 & Numuns) || convvtox(vv, TVLONG) < 0) {
> + if(c1 & Numvlong ||
> + convvtox(vv, TUVLONG) > convvtox(vv, TULONG) ||
Since the return type of convvtox is vlong, I don't think this behaves
as you expect.
If we have "0xffffffffffffffff", then vv == -1LL. So convvtox(-1LL,
TUVLONG) == -1LL and convvtox(-1LL, TULONG) == 0xffffffffLL, which
means this condition fails (-1LL < 0xffffffffLL), and we end up not
choosing a 64-bit type.
> + (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TLONG) < 0) {
> + if((c1 & (Numdec|Numuns)) == 0 &&
Indentation is a bit weird here. I think there are some leading spaces.
> + ((c1 & Numuns) || convvtox(vv, TVLONG) < 0)) {
Something is funny with the logic here. In the LHS of the &&, you
checked that c1 has neither Numdec or Numuns, so it is impossible that
c1 has Numuns here.
I haven't tested, but I think we'd end up with 0ULL having type vlong,
not uvlong (hit the first case in the outer if-statement, and fail the
first case in the inner if-statement).
Maybe the following is correct?
if((c1 & Numuns) || !(c1 & Numdec) && convvtox(vv, TLONG) < 0)
> c = LUVLCONST;
> t = TUVLONG;
> goto nret;
> @@ -867,8 +861,11 @@
> t = TVLONG;
> goto nret;
> }
> - if(c1 & Numlong) {
> - if((c1 & Numuns) || convvtox(vv, TLONG) < 0) {
> + if(c1 & Numlong ||
> + convvtox(vv, TULONG) > convvtox(vv, TUINT) ||
> + (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TINT) < 0) {
> + if((c1 & (Numdec|Numuns)) == 0 &&
Same problem here. Maybe
if((c1 & Numuns) || !(c1 & Numdec) && convvtox(vv, TLONG) < 0)
instead?
Trailing space on this line.
> + ((c1 & Numuns) || convvtox(vv, TLONG) < 0)) {
> c = LULCONST;
> t = TULONG;
> goto nret;
Also, just want to throw out an alternative table-based approach (what
I'm doing in cproc) that has a lot less logic. Not even compile
tested, but something like
static struct {
long t, c, c1;
} inttypes[] = {
{TINT, LCONST, 0},
{TUINT, LUCONST, Numuns},
{TLONG, LLCONST, Numlong},
{TULONG, LULCONST, Numuns|Numlong},
{TVLONG, LVLCONST, Numvlong|Numlong},
{TUVLONG, LUVLCONST, Numuns|Numvlong|Numlong},
};
for(i = 0; i < nelem(inttypes); i++){
if((c1 & (Numuns|Numlong|Numvlong)) == inttypes[i].c1)
break;
}
for(; i < nelem(inttypes); i += c1 & (Numuns|Numdec) ? 2 : 1)
t = inttypes[i].t;
c = inttypes[i].c;
if(vv <= 0xffffffffffffffffu >> 64 - 8 * ewidth[t] + !typeu[t])
break;
}
^ permalink raw reply [flat|nested] 2+ messages in thread