Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: size_t vs long. Date: Fri, 02 Dec 2022 10:18:31 -0800 Organization: None to speak of Lines: 56 Message-ID: <878rjpk6tk.fsf@nosuchdomain.example.com> References: <5a71fdad-b7d6-4b4a-a3ee-c5a9beb75d28n@googlegroups.com> <3cd9fa14-f717-40b6-a430-5b6f609fcdc7n@googlegroups.com> <1b4juk47wa.fsf@pfeifferfamily.net> <87h6yfj90p.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="247fe790ac1ec28cfc3dce872b2dc81e"; logging-data="3287001"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/QUPAaa4GzsXEduMKyf9vR" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:Ftuc9xkFemnBv4FzSVQth6++INs= sha1:i6yui0pfBEcrkdWR4sxEkjyWZFc= Xref: csiph.com comp.lang.c:168447 A writes: [...] > Basically, my point is that if something is specified in the standard, > then it doesn't mean that it should be used by everyone. After all, > the standard was defined by humans only. > > Multiple inheritance is a feature of C++. But google recommends its > developers to not use multiple inheritance when writing C++ code. So, > google is not following C++ standards completely. So, do you think > that google is wrong? > > What I am saying is that size_t may be preferred by many people. But > many people may not like it size_t. They may want to use long. So, why > force them to use size_t when using long is not introducing any bug? size_t is used extensively in the C standard library. You can't avoid it if you're programming in C. (You can at least mostly avoid multiple inheritance when programming in C++. I offer no opinion on whether that's a good idea or not.) > I thought a lot about why would they specify size_t in the C standard > in memcpy(), etc. - the only reason that comes to my mind is that they > thought that they don't know what kind of systems will come in the > future. So, why to restrict the developer by using a signed > type. Instead, give the user the whole range. They didn't know what kinds of systems will appear in the future, and they *did* know what kinds of systems already existed. Existing systems have different characteristics. It makes sense for size_t to be 16 bits on some systems, 32 on some, and 64 on some. And each implementation defines it with an appropriate width for the target system. > But some people said that the size of type size_t differs according in > various systems/implementations. Again, defining this kind of size_t > is wrong. I don't understand whatever point you're making here. size_t is already defined appropriately for each implementation, based on the characteristics of the target system. Were you not aware of that? > If you really want to address the whole memory range (so that the user > is not restricted because no one knows what kind of systems may come > in future), the size of type size_t should be set equal to the width > of the address bus of the system to address the whole memory range > (whether available or not) (and probably get this value dynamically). It typically *is* the width of the address bus (or it might be different for some valid reason). The developers of the implementation have that information, and use it when writing the header and the various functions that take size_t arguments. There's no need to compute it dynamically. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */