Building cmd I noticed that the case of sizeof(int) = sizeof(long)
(which is the case in all compilers) wasn't managed with my changes.
I wonder if this logic mess could be shortened without making
impossible to read the 'if' conditions without throwing up (I've
tried).
I've compiled on arm the
Arrrg!
[...]
vv = yylval.vval;
if(c1 & Numvlong ||
(uvlong)convvtox(vv, TUVLONG) > convvtox(vv, TULONG)){
/* unsigned suffix or hex occupying the sing bit */
if((c1 & Numuns) || convvtox(vv, TVLONG) < 0 && (c1 & Numdec) ==
0) {
I think I got it right at last:
[...]
vv = yylval.vval;
if(c1 & Numvlong ||
(uvlong)convvtox(vv, TUVLONG) > convvtox(vv, TULONG)){
/* unsigned suffix or hex occupying the sing bit */
if((c1 & Numuns) || convvtox(vv, TVLONG) < 0 && (c1 &
On Sun, 1 May 2022, adr wrote:
Yeah, i was thinking
int -> long -> vlong -> uvlong
No, it was a mistake, I forgot to check again that the conversion to
unsigned when the constant is using the sign bit doesn't occurs to
decimal constants.
Also, reading 9front's mailing list I noticed the
I think this gets the condition slightly wrong. For a decimal
number, we should promote:
int -> long -> vlong.
Yeah, i was thinking
int -> long -> vlong -> uvlong
when I wrote that, nice catch!
--
9fans: 9fans
Permalink:
it's synced.
Nice.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-Mdbeaa9de34cf64c195becdec
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth o...@eigenstate.org:
> I think we want:
I mean:
if(c1 & Numvlong ||
convvtox(vv, TUVLONG) > convvtox(vv, TULONG) ||
(c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TLONG) < 0) {
if((c1 & (Numdec|Numuns)) == 0 &&
((c1 & Numuns)
Quoth adr :
> On Wed, 20 Apr 2022, o...@eigenstate.org wrote:
> > When you have a patch, let me know -- I'll happily test
> > and apply to 9front.
>
> Hi ori, this patch applyes to the sources served at 9front.org.
> By the way, do you plan to keep in sync
>
Quoth adr :
>
> Hi ori, this patch applyes to the sources served at 9front.org.
> By the way, do you plan to keep in sync
> http://only9fans.com/ori/git9/HEAD/info.html or should I forget
> about that repo?
it's synced.
--
9fans: 9fans
Permalink:
Quoth adr :
> On Wed, 20 Apr 2022, o...@eigenstate.org wrote:
> > When you have a patch, let me know -- I'll happily test
> > and apply to 9front.
>
> Hi ori, this patch applyes to the sources served at 9front.org.
Highly appreciated -- I'm busy this week, but I'll take a look
in the coming
On Wed, 20 Apr 2022, o...@eigenstate.org wrote:
When you have a patch, let me know -- I'll happily test
and apply to 9front.
Hi ori, this patch applyes to the sources served at 9front.org.
By the way, do you plan to keep in sync
http://only9fans.com/ori/git9/HEAD/info.html or should I forget
Quoth adr :
> Some thoughts to help me decide what to do in my dist?
The c99 rule is probably the one to follow, along side
the plan9 unsigned preserving rule.
When you have a patch, let me know -- I'll happily test
and apply to 9front.
--
9fans: 9fans
On Wed, 20 Apr 2022, Charles Forsyth wrote:
The short answer is whatever the historical reasons for the current
interpretation(s), it
should follow C99 rules to avoid confusion.
This should do the trick. I hope to not have to send another patch in half an
hour...
Charles, you are part of
The short answer is whatever the historical reasons for the current
interpretation(s), it should follow C99 rules to avoid confusion.
One potential catch is that the compilers don't implement C99 rules when
signed and unsigned values meet, but something closer to the original
convention
(which
Hi.
I've been tinkering again with the dist I shared before in
http://adr.freeshell.org/plan9, basically 9legacy + Miller's 9pi
+ 9front's libseq. Importing ori's git9 I noticed that the compiler
was truncating a constant without the correspondent suffix.
According to C99, the type of a
15 matches
Mail list logo
