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: What is the rank of size_t ? Date: Wed, 27 May 2020 14:30:00 -0700 Organization: None to speak of Lines: 22 Message-ID: <87sgflxe07.fsf@nosuchdomain.example.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="a8f11619dd611f7a15b76e5236c8efe8"; logging-data="8727"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+s7dgcjLMIhaalypO7X4L0" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:bJNnRp19kOWHAN38Mo/fvGsVg7A= sha1:Z//6UXy9bx3hI1N2VrfzdBedXj8= Xref: csiph.com comp.lang.c:152512 Vir Campestris writes: > On 27/05/2020 14:59, James Kuyper wrote: >> size_t is a typedef, and the only portable guarantee you have is that >> it's a typedef for an unsigned integer type with a maximum value no less >> than 65535; > > Must it be a typedef for one of the common types? No, it can be a typedef for an extended integer type. > It occurs to me that there are some architectures where the address > space size is not a common integer. Some of the 8086 modes, for > example, will allow a megabyte of address space (20 bit). Such a system will typically make size_t bigger than it strictly needs to be. An implementation for an 8086 can provide 32-bit integers much more easily than it can provide 20-bit integers. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */