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: Wed, 23 Oct 2019 05:42:25 -0700 Organization: A noiseless patient Spider Lines: 80 Message-ID: <86a79rhbv2.fsf@linuxsc.com> References: <5alnF.1041354$WI2.353384@fx34.am4> <87tv8ggaxh.fsf@bsb.me.uk> <87mue8fx7b.fsf@bsb.me.uk> <1QInF.797536$aq7.506537@fx09.am4> <875zkwf27e.fsf@bsb.me.uk> <87a7a66eyk.fsf@bsb.me.uk> <05020370-4edc-457f-a038-f51efbb47cdf@googlegroups.com> <87tv8d4kys.fsf@bsb.me.uk> <3obpF.121293$LC2.25145@fx45.iad> <86tv874jsq.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="09129d99e56165cafc27964696c7f4e6"; logging-data="29981"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ReySCinQM+uf5/+fxeRGaAEcYeBodDYg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:mEmCRB0gRjAtAFrPg0sTtqZ3mzI= sha1:/b82s8SQm7HQygJI/3qYdd2FG/Q= Xref: csiph.com comp.lang.c:147172 Keith Thompson writes: > Richard Damon writes: > >> On 10/17/19 8:51 AM, Tim Rentsch wrote: >> >>> Richard Damon writes: >>> >>>> C has 11 standard integer types. PERIOD. >>> >>> An argument could be made that C has 12 standard integer types, >>> since 'signed int' is not perfectly identical to 'int'. (The >>> difference arises in declaring bitfield members.) Besides that >>> miniscule exception though you assertions are spot on. >> >> Except that for a bit field, the declaration of the type of a field as >> int doesn't create a type that is distinct from signed int and unsigned >> int like char does, but is implementation defined if int is to be >> considered as signed int or unsigned int. In other words, no bit field >> member has a type of 'int', but only signed int or unsigned int, and a >> field declared as just int will be treated as one or the other as >> defined and documented by the implementation. > > Yes. > > N1570 6.7.2p5: > Each of the comma-separated multisets designates the same type, > except that for bit-fields, it is implementation-defined whether > the specifier int designates the same type as signed int or > the same type as unsigned int. > > (The "multisets" include "int", "signed int", and "signed", for > example. The term "multiset" is used rather than "set" because > "long long" is distinct from "long".) > >> If I am reading the standard right, I think that decision only applies >> to the literal string int (or after macro replacement), and not for a >> typedef. > > That's not the intent, though I agree that it's implied by the normative > wording. N1570 footnote 125 on 6.7.2.1p10 says: > > 125) As specified in 6.7.2 above, if the actual type specifier > used is int or a typedef-name defined as int, then it is > implementation-defined whether the bit-field is signed > or unsigned. > > But by referring to "the specifier int" (a syntactic construct) > rather than the type int, 6.7.2p5 fails to make that clear. > (The name of a typedef defined as int is not "the specifier int".) This statement, and whether there is normative wording supporting footnote 125, depends on how 'typedef' is defined. The semantics of 'typedef' is given in 6.7.8 p3. I have no firm conclusions on how the relevant passages there should be parsed (except to say they are sorely in need of clarifying). Note however the example in 6.7.8 p6: EXAMPLE 3 The following obscure constructions typedef signed int t; typedef int plain; struct tag { unsigned t:4; const t:5; plain r:5; }; declare a typedef name t with type signed int, a typedef name plain with type int, and a structure with three bit-field members, one named t that contains values in the range [0, 15], an unnamed const-qualified bit-field which (if it could be accessed) would contain values in either the range [-15, +15] or [-16, +15], and one named r that contains values in one of the ranges [0, 31], [-15, +15], or [-16, +15]. (The choice of range is implementation-defined.) [...] This example clearly shows that the authors consider typedef's normative semantics to distinguish between 'signed int' and 'int'.