Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Loops (was Re: do { quit; } else { }) Date: Thu, 17 Apr 2025 15:32:05 -0700 Organization: None to speak of Lines: 55 Message-ID: <87bjsupggq.fsf@nosuchdomain.example.com> References: <20250415053852.166@kylheku.com> <20250416142925.663@kylheku.com> <20250416164536.110@kylheku.com> <87ikn3zg18.fsf@nosuchdomain.example.com> <87fri68w2c.fsf@nosuchdomain.example.com> <87fri6pnpo.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 18 Apr 2025 00:32:09 +0200 (CEST) Injection-Info: dont-email.me; posting-host="296572f88f5dccb657107911794e9333"; logging-data="1696378"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+YCwnXA3bDq/VVDpWP4HhW" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:prXwOM0tI+LYIhql742R/6w2V6c= sha1:2rpX2BigeGmovjwddx+6eBMgtrc= Xref: csiph.com comp.lang.c:392663 bart writes: > On 17/04/2025 20:55, Keith Thompson wrote: >> bart writes: > >> Here's what you wrote upthread: >> What's far more useful is that it naturally works with i64 >> so has limits 4 billion times bigger than you get with C's >> default 'int' type. >> Here's what you could have written: >> What's far more useful is that it naturally works with >> i64 so has limits 4 billion times bigger than you get with >> 32-bit int. >> That's clearer, shorter, and correct, and would have avoided this >> entire subthread. I would not have commented on it. > > But it misses out the important bit. Clearly i64 has 2**32 times the > range of i32; that will be the case in any context. I don't see what "important bit" my proposed wording would have missed. Can you clarify? > What's relevant here is that my language's "don't care" 'int' type > defaults to 64 bits, while C's 'int' type, on pretty much any PC from > this century, will default to 32 bits. I don't think "default" is the right word here. I'll explain why if you ask. > Which means people are more likely to encounter problems involving > wrap, or UB. Right, which would have been crystal clear if you had written "32-bit int" rather than falsely asserting that 32 bits is some kind of "default". The phrase "32-bit int" makes it clear that you're discussing implementations on which int is 32 bits wide (which is very common), without falsely implying that a width of 32 bits is required or "default". And it would demonstrate an understanding of the difference between "C" and "most implementations of C" (or "most hosted or PC implementations of C). > Whether C's 'int' should have moved to 64 bits on 64-bit machines has > been discussed here in the past. More correctly, whether C implementations for 64-bit machines should make int 64 bits has been discussed here in the past. C has always permitted int to be 64 bits if chosen by the implementation. > That would have kicked such problems a /long/ way down the road. Yes, for those implementations, but it would have caused other problems (which might be an interesting topic for another thread). -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */