Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: size_t vs long. Date: Sun, 04 Dec 2022 07:35:08 -0800 Organization: A noiseless patient Spider Lines: 54 Message-ID: <867cz75gib.fsf@linuxsc.com> References: <5a71fdad-b7d6-4b4a-a3ee-c5a9beb75d28n@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="a7bd75a4d2e37668b26a7417afa0cbc4"; logging-data="3899080"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/jj9skjBQ3o5GeAE5nA2z9HRl13BwAf1s=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:nT/sfMGQ9qaOrnV5J1G9oHN4zSY= sha1:L3w38y1/dSt7u9CqKJ9gM1ggN7E= Xref: csiph.com comp.lang.c:168485 Amit writes: > I prefer long over size_t. > > This is because, in case the user passes a negative number by mistake > then I will be able to check it if the type is long and return > immediately. > > But if size_t is used, then most probably, it will result in a crash > - like malloc(-1) will crash the program because unsigned -1 is > 0xFFFFFFFF and this much memory is not available on today's computers > and probably may not be available at all in future also (RAM size of > 2^64 bits is really really huge). > > Another thing is that if size_t is used an array index then array[-1] > will result in wrong behavior or program crash. But with long, the > developer can check whether the index is negative, thus avoiding > program crash. > > So, in my opinion, long should be used instead of size_t. > > I know that original glibc authors had chosen size_t, so there must > be some reason for that, however that reason is not clear to me. I have been reading through your postings in this thread. Here are my main impressions. First, your conclusions are bad. This result occurs because, one, some of your assumptions are wrong, and two, your logic is faulty. Second, it appears you are fundamentally confused about the nature of types defined in the ISO C standard. Most types defined in the ISO C standard allow some amount of variation in choices for their precision, representation, etc. These choices are left up to the various implementations, and it is expected that each implementation will make its own choices in a way most suitable to the implementation's execution environment. This variability has been in place for more than 30 years (closer to 40 years if you count the time after the C standardization effort was started); it works pretty well, and has not presented any serious difficulties in carrying it out. Third, there is nothing wrong with wanting to check for negative arguments to functionalities such as memory allocation, etc, but you are conflating that high-level desire with one particular approach to addressing it, and that approach (using a 'long' parameter) is inherently flawed. It appears you simply do not understand why that is. If you want to make any progress, you must learn how to separate these different aspects and deal with them individually. Otherwise what you are advocating is just a muddled mess, and no competent software developer is going to take you seriously.