Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Abstract Syntax Tree for C programs Date: Thu, 30 May 2019 15:39:17 -0700 Organization: None to speak of Lines: 58 Message-ID: References: <80470a36-78de-417f-bc75-a7966c87b31e@googlegroups.com> <9cbcea67-85a8-4de3-ac01-04922ba5fc74@googlegroups.com> <7cff3be5-0432-4a90-92ed-50c74cc1eb6b@googlegroups.com> <87y32oj208.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="75605edc6d5df8cff0a246a2f96c1385"; logging-data="24246"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+WkM996TXYG3lBZYcTqhEd" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:VhSs3CnVBYUMvBVeHC5LMagSTBw= sha1:J6tVKmkLdWRp2Gk5YRZAanX5U1Y= Xref: csiph.com comp.lang.c:144160 Bart writes: > On 30/05/2019 22:15, Keith Thompson wrote: >> Bart writes: >> [...] >>> It seems reasonable. That u8+u8 produces a signed result is >>> counter-intuitive and surprising. (My table was produced by turning >>> results of assorted calculations into floats, but that can't pick up >>> u8+i8->i32. I know see I should have used generics.) >>> >>> What I had always assumed (wrongly) was that mixed sign arithmetic was >>> done as unsigned, irrespective of widths: >> [...] >> >> You could have saved yourself a lot of time and trouble if you had just >> read the relevant part of the C standard. > > You mean this: > > "If both operands have the same type, then no further conversion is needed. > > Otherwise, if both operands have signed integer types or both have > unsigned integer types, the operand with the type of lesser integer > conversion rank is converted to the type of the operand with greater rank. > > Otherwise, if the operand that has unsigned integer type has rank > greater or equal to the rank of the type of the other operand, then the > operand with signed integer type is converted to the type of the operand > with unsigned integer type. > > Otherwise, if the type of the operand with signed integer type can > represent all of the values of the type of the operand with unsigned > integer type, then the operand with unsigned integer type is converted > to the type of the operand with signed integer type. > > Otherwise, both operands are converted to the unsigned integer type > corresponding to the type of the operand with signed integer type." Yes, that and the part about the "usual arithmetic conversions", which are applied to both operands of most 2-operand operators. The part you quoted applies after those conversions. > Yeah, that's as clear as mud. > > > You could have saved yourself a lot of time and trouble if you had just > > read the relevant part of the C standard. > > More likely the opposite. If you have trouble understanding it, you could ask for help. Your previous attempt to understand the rules led you to some incorrect conclusions. If I were you, I'd try something else. Reading the standard worked for me. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */