Deutsch English Français Italiano |
<5b0afc722e98a2f3caa6aea97c77ab8a@www.novabbs.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Wed, 4 Sep 2024 16:32:37 +0000 Organization: Rocksolid Light Message-ID: <5b0afc722e98a2f3caa6aea97c77ab8a@www.novabbs.org> References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me> <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me> <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me> <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me> <vb2hir$1ju7q$1@dont-email.me> <jwv34mgo7sz.fsf-monnier+comp.arch@gnu.org> <9a76aa4fdf15830a4b89aaca28e72754@www.novabbs.org> <vb927t$3nlvo$5@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="848380"; mail-complaints-to="usenet@i2pn2.org"; posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A"; User-Agent: Rocksolid Light X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Site: $2y$10$Lv3Qdq/255dzjZ8X6wd6HOFXIfraXAoAigPWdJQvmdYEOJu76Cs/e Bytes: 2407 Lines: 28 On Wed, 4 Sep 2024 7:29:01 +0000, David Brown wrote: > On 03/09/2024 22:22, MitchAlsup1 wrote: >> On Tue, 3 Sep 2024 19:30:21 +0000, Stefan Monnier wrote: >> >>>> Specifications are an agreement between the supplier and the client. The >>> >>> The problem here is that the C standard, seen as a contract, is unfair >>> to the programmer, because it's so excruciatingly hard to write code >>> that is guaranteed to be free from UB. >> >> # define int int64_t >> .. >> >> makes it easier. > > That's UB, I believe :-) And it will certainly be confusing. On 64-bit machines it re-establishes the dusty-deck old K&R C where int was the fastest integer type. > But good use of size-specific types is helpful to writing correct code. > If your calculations could conceivably overflow 32 bits, int64_t is a > good choice. > > For smaller numbers and portable code, you might want int_fast32_t or > int_fast16_t, which on most 64-bit systems will be faster than "int". > > You can call it /ugly/, but it's not /hard/.