Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Sort char array
Date: Thu, 10 Oct 2019 12:20:07 -0700
Organization: None to speak of
Lines: 33
Message-ID: <lnpnj4tnko.fsf@kst-u.example.com>
References: <STKlF.8551$oU2.5908@fx21.iad> <ln8spxwt12.fsf@kst-u.example.com> <L5smF.695441$VT3.152510@fx19.am4> <OnvmF.779760$RU2.307870@fx21.am4> <lnzhidv1ie.fsf@kst-u.example.com> <e2c6fd6e-be6b-4320-b4ce-09f574f40fd2@googlegroups.com> <n0EmF.2667134$c8w1.1556251@fx08.am4> <20191007131948.c9f28d44bcd105e7a153069a@g{oogle}mail.com> <2xFmF.867378$yH4.431562@fx18.am4> <qnf974$aiu$1@dont-email.me> <XyHmF.665592$qd4.648019@fx17.am4> <20191007174244.385138503569a8bc6d4eec9d@g{oogle}mail.com> <rvKmF.2513170$dw4.1447457@fx12.am4> <20191008022725.36fbd95aa45ba185290e5e11@gmail.com> <1q_mF.841756$Zy3.585129@fx33.am4> <20191009020207.b533aa1c6d95f44eb314ffc1@gmail.com> <Pg9nF.750165$bS1.468151@fx13.am4> <20191010030322.2da081faffb190e4f5370362@gmail.com> <65b3e46e-3d3e-4a4b-8e5d-7bcc908019b6@googlegroups.com> <lntv8gtr12.fsf@kst-u.example.com> <qnnthp$b4v$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="ae453da06a2b0ba7b51610fa3f87a41c"; logging-data="27147"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1863naWumsMQOWzSX7JDOz3"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:gCxtssNEdkY1BtH09y3k+s6VO4g= sha1:dYSDlNWEMndlJ8OBq86pmhsUv7Y=
Xref: csiph.com comp.lang.c:146848

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
> In my programming experience, I've found it useful not to think of 
> arithmetic objects (like shorts, ints and longs) in terms of their memory 
> size, but instead in terms of the ranges of values that they can hold.
>
> It is not often (afaicr, never) that I've found myself thinking "I've got 16 
> bits of space, what values can I store in it?". More often (always, afaicr) 
> I've said "I have a need to store a value between <<something>> and 
> <<something else>>; what sort of object can store that?"
>
> I see no need to preoccupy myself with arguments about the "bit width" of 
> various C arithmetic objects; I find such discussions counterproductive to 
> the task of writing programs.

Agreed -- and in fact that's how the standard specifies the
requirements.  The sizes in bits (for example, int is at least 16
bits) can be inferred from the range requirements and the requirement
for pure binary notation.

An exception is when an external interface imposes a specific
size requirement.  (Even then, the size requirement is usually
based on a need to hold some range of values.)  Another is when
an unsigned integer is used to hold flag values (you can store at
least 16 flags in an unsigned flag, 32 in a uint32_t, etc.).

On the other hand, it's easier to say "at least 64 bits" than
"at least 0 to 18446744073709551615".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */