Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: How About Disallowing Assignments In Expressions? Date: Wed, 14 Feb 2024 14:47:02 -0800 Organization: None to speak of Lines: 46 Message-ID: <87o7ci8xzt.fsf@nosuchdomain.example.com> References: <87r0hlef8q.fsf@nosuchdomain.example.com> <87sf20o4e2.fsf@bsb.me.uk> <87a5o3amit.fsf@nosuchdomain.example.com> <20240214120232.00001d56@yahoo.com> <871q9f9go2.fsf@nosuchdomain.example.com> <87a5o2lrd2.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="f0324011426819b9e4b7ac5a3d98873d"; logging-data="2999524"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18hHwUKsGJZK4R0xeyxZDU3" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:+VdPHQqgkZ3+75Yg0VqifLD78fo= sha1:vySprvftE+8ZkJjJsjm3AlyZvT8= Xref: csiph.com comp.lang.c:382500 scott@slp53.sl.home (Scott Lurndal) writes: > Ben Bacarisse writes: >>Keith Thompson writes: [...] >>> There's no suffix for uint64_t. 0ul is of type unsigned long, which may >>> or may not be the same type as uint64_t. >>> >>> In this particular case, I'd just use 0. If for some reason I needed to >>> make it explicitly of type uint64_t (say, for an argument to a variadic >>> function), I'd write `(uint64_t)0`. >> >>stdint.h also provides an UINT64_C(...) macro that could be used, >>though, as you say, 0 is really all that's needed in this case. > > OTOH, all the systems the code in question run typedef uint64_t to unsigned > long, so the 'ul' suffix works correctly in all forseeable usages in this > application. And it's less to type than casting. Granted it's not > particularly meaningful in the 0ul case, but it's a habit that does > come in handy in expressions like > > uint64_t address; > address = (0xcul << 44) | ((uint64_t)node << 44) | (device << 32) | register_offset; > > Yes, a cast on the constant would work as well. And yes, a good compiler > will warn if the suffix is missing from the first constant value. There are certainly systems (including Windows and 32-bit Linux) where unsigned long is 32 bits. On such systems uint64_t is likely to be defined as unsigned long long. Even where unsigned long is 64 bits, an implementation could define uint64_t as unsigned long long. I think it's a bad idea to make assumptions about which underlying types are used for the fixed-width types. I might write the above as: uint64_t address; address = ((uint64_t)0xc << 44) | ((uint64_t)node << 44) | (device << 32) | register_offset; (I presume device and register_offset are of type uint64_t.) I don't think I've ever used the UINT64_C() macro, but that's another possibility. It's less ugly than the format macros in . -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Medtronic void Void(void) { Void(); } /* The recursive call of the void */