From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30664 invoked from network); 5 May 2022 18:23:55 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 5 May 2022 18:23:55 -0000 Received: from mail-ej1-f53.google.com ([209.85.218.53]) by 9front; Thu May 5 14:20:41 -0400 2022 Received: by mail-ej1-f53.google.com with SMTP id bv19so10282992ejb.6 for <9front@9front.org>; Thu, 05 May 2022 11:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=kTdA9TUV0rrJQdytnGpjPaEVNiyuc8+aIep/SJGsnDs=; b=S3uh9Op19RFoVdUYNYV8mIj8b2rOAVDrM6R719nlIs0/rLfYcQtez7mpJ9V8CfqMPj dWW24WOjXX6qH70WlXL3rrDYeZRazA0b9A4E6POS1doWJITdGAEK2qxKvu8hSkCiziKe FrOV2roKkSr9NltDtHdJCpYvl/kAi/3VyfFB2BVromkGU4/PGRTccfhk7PQTSQmdWl58 LFN6GuNY16LpYYkiamJORu9eZPAo4G4+CzLBj7IzEpySNtFwsq4nkspkQvHkAdndJQ2b 8J/42f1U4KjlpKZriOpwe3/IFgP+ddly1NNYBbwGSgzM6WcdXH+7Ao4qULOFo3K3aHUU rh5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kTdA9TUV0rrJQdytnGpjPaEVNiyuc8+aIep/SJGsnDs=; b=UI3KQCAF8aIZKMbV44IfhfYH576UlOycgNboPDI28nhaw9DjpeQMMjBgFU7EiRKDtd T5bMgTdLRNcGidNWlh6XDsCRYufcfW9WUkm6B9SQsqRSfnAGfGqkvMBajLreeW1fkcRx o4AMBZgSgVju0YYvNnA6BWKwqihlDAhKDlC2cepywl51ZGF8vdh0/wZ5NHgZqJ7Xd/0l wc9U0eZLCB4QwxZs+Qrhn+4BoviVlUDy6jHi/W0x+Td51YfBJFQe6YJsf5x9xwZBNrqT 84WDzJB9rM6piTl9hVeY8Q8dlEztr0dCW+SDaTHHfJeI4Jrc0eI8Tc2FI4K9FtRSZR+j TUWA== X-Gm-Message-State: AOAM531QCY5IUE+7m37dmwe9DgtUlsTDjRQds9Hni0lB9WlXz/n4x+2w QjU3irAuZKusAxtBh355iGoVEGjSV7gpf1Ie2PR03cEPFycG6w== X-Google-Smtp-Source: ABdhPJxxKrNY6rIYJc9APpPZdFL76XN1FVjJbfWbTbMzFFN91fazob9URxvTrcSe/DMuoQwQYkuA9uGPyTuLOdCpyZg= X-Received: by 2002:a17:907:94d2:b0:6f4:b5f9:6f3a with SMTP id dn18-20020a17090794d200b006f4b5f96f3amr10809394ejc.313.1651774835682; Thu, 05 May 2022 11:20:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:906:6782:b0:6d0:9087:adfd with HTTP; Thu, 5 May 2022 11:20:33 -0700 (PDT) X-Originating-IP: [98.45.152.168] In-Reply-To: <13CBD0AF060D51D940C5C190309C99E9@eigenstate.org> References: <13CBD0AF060D51D940C5C190309C99E9@eigenstate.org> From: Michael Forney Date: Thu, 5 May 2022 11:20:33 -0700 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: strategy extension WEB2.0 general-purpose-scale hardware cloud Subject: Re: [9front] cc: fix conversion of constants to match c99. Reply-To: 9front@9front.org Precedence: bulk On 2022-05-05, 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< - 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; }