Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Sort char array Date: Mon, 14 Oct 2019 08:57:15 -0700 Organization: A noiseless patient Spider Lines: 74 Message-ID: <86a7a3721w.fsf@linuxsc.com> References: <20191007131948.c9f28d44bcd105e7a153069a@g{oogle}mail.com> <2xFmF.867378$yH4.431562@fx18.am4> <20191007174244.385138503569a8bc6d4eec9d@g{oogle}mail.com> <20191008022725.36fbd95aa45ba185290e5e11@gmail.com> <1q_mF.841756$Zy3.585129@fx33.am4> <20191009020207.b533aa1c6d95f44eb314ffc1@gmail.com> <5alnF.1041354$WI2.353384@fx34.am4> <87tv8ggaxh.fsf@bsb.me.uk> <87mue8fx7b.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="d0509592842f78811f1490d2ec487131"; logging-data="28636"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/9bH/Nmv16WcI0atkt7kD7q8eYaVAKEnE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:4FycvIVyEZuOfeAJwbGtLvnBiKQ= sha1:EWNRYxlR4r+BiY2ngclsVCBzt0o= Xref: csiph.com comp.lang.c:146957 Ben Bacarisse writes: > Bart writes: > >> On 10/10/2019 11:19, Ben Bacarisse wrote: >> >>> Malcolm McLean writes: >>> >>>> On Wednesday, 9 October 2019 19:32:07 UTC+1, David Brown wrote: >>>> >>>>> It is only pointers to these types that lead to compatibility issues, >>>>> not the types themselves. But yes, you need to deal with this somehow. >>>>> Often I think it is a good idea to consider the fixed size types and >>>>> the base types as parallel sets of types - pick one set that is >>>>> appropriate for the type of code, and use it. >>>> >>>> C integers are a joke. I've forgotten how many types there are in >>>> standard C, but I think it was something like forty. When the >>>> underlying hardware will support only 8, 16, 32, 64 maybe 128 bit. >>> >>> That appears to be a deeply disingenuous remark. The number of integer >>> types in C has almost nothing to do with the number of bit widths any >>> one (or even all) hardware supports. You appear to be setting up a >>> false comparison for purely rhetorical purposes. >> >> Typically, for C on desktop and other consumer machines, C supports >> the FOUR widths 8, 16, 32 and 64 bits, via the FIVE types char, short, >> int, long, long long, none of which actually pin down their widths. > > SIX types -- you've forgotten signed char. You are also putting aside > (I'm sure you haven't forgotten) the unsigned integer types, which > include another character type and _Bool which is not like any of the > others. > >> And ALSO via int8_t, int16_t, int32_t and int64_t. [..etc..] My comment here is not exactly a response but this seems like a reasonable place in the thread to make it, and so here we are. Reading through the various postings, it struck me that there is a difference in viewpoints which could be explained by some observations made by Dijkstra and James Morris. The Dijkstra observation is about the two views of programming. In the old view, the purpose of our programs is to instruct our machines. In the new view, the purpose of machines is to execute our programs. This change of viewpoint is a profound shift. The Morris observation is captured by the title of his seminal paper, "Types are not sets" (here is a link for people who have not seen the paper: http://www.cs.fsu.edu/~langley/COP4020/2016-Summer/p120-morris.pdf ). The difference in viewpoints we are seeing here can be understood by the observations of Dijkstra and Morris. The people who think C has too many types are those who have not yet made the shifts described by Dijkstra and Morris. They think of "type" as being synonymous with representation, and at least in this area their thinking is mostly at the level of assembly language. Speaking for myself, there are times in programming when I do deliberately take the perspective of what's going on at the assembly language level, but mostly I don't, because it gets in the way of seeing what is going on at a higher level. Since the most important parts of program understanding involve seeing what is going on at higher levels of abstraction, the vast majority of the time I avoid thinking at the assembly language level, because doing so hurts more than it helps. These observations may help us understand the comments of people who think C's type model is somehow bad or wrong.