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: Fri, 18 Oct 2019 06:57:31 -0700 Organization: A noiseless patient Spider Lines: 79 Message-ID: <86zhhygnqs.fsf@linuxsc.com> References: <20191008022725.36fbd95aa45ba185290e5e11@gmail.com> <1q_mF.841756$Zy3.585129@fx33.am4> <20191009020207.b533aa1c6d95f44eb314ffc1@gmail.com> <5alnF.1041354$WI2.353384@fx34.am4> <5b525fc7-aeb6-47ec-b425-526a60d31e92@googlegroups.com> <86bluh54he.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="d91397d7fe4ac661113bfb37d068a0d4"; logging-data="28366"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18LQTwwwr0ujicYAIUOKC8Ng8djtAwUrI4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:iQRxwEdftRSnawoWt6YfWLp3G9o= sha1:uOcq4l2v8+bM6WZrZBTF4Ka4UEc= Xref: csiph.com comp.lang.c:147028 Keith Thompson writes: > James Kuyper writes: > >> On 10/16/19 5:21 PM, Keith Thompson wrote: >> >>> Tim Rentsch writes: >>> >>>> James Kuyper writes: >> >> ... >> >>>>> though the standard fails to mandate it. If so, and you #include >>>>> , then INT128_C(123456789012345678901234567890123456789) is >>>>> required to expand to an integer constant expression with the same type >>>>> as the promoted type of int_least128_t (7.20.4.1). >> >> ... >> >>>> I believe it could be done completely portably as follows: >>>> >>>> #define INT128_C(n) (INT_LEAST128_MAX - INT_LEAST128_MAX + n) >>> >>> 7.20.4p1 requires INTn_C(value) to expand to an integer constant, not >>> just an integer constant expression. I'm not sure that requirement is >>> necessary (i.e., I'm not sure we'd lose anything if it were allowed more >>> generally to be an integer constant expression), but there it is. >> >> "The macro INTN_C(value) shall expand to an integer constant expression >> corresponding to the type int_leastN_t." (7.20.4p1). > > That's 7.20.4.1p1. 7.20.4p1 says: > The following function-like macros expand to integer constants > suitable for initializing objects that have integer types > corresponding to types defined in . > > Of course an integer constant is an integer constant expression, > but I don't know why the paragraph you quoted uses the more general > term when the paragraph above it uses the more specific term. > It's hard to tell what the intent is. I think this is a flaw in the > standard. (The same flaw appears in the latest draft, N2386.) To me it seems clear that the requirement is meant to be an integer constant expression (that may be used in a #if directive), and not limited to 'integer constant' as defined in 6.4.4.1. Consider the following: * The quoted sentence in 7.20.4 p1 looks like a description more than it does a requirement. In particular, it does not contain the word "shall". * The second paragraph, 7.20.4 p2 (which incidentally does use the word "shall"), says explicitly "as defined in 6.4.4.1" when it means to refer specifically to the syntactic form. * The third paragraph, 7.20.4 p3, says "Each invocation of one of these macros shall expand to an integer constant expression suitable for use in #if preprocessing directives." Surely that sentence is meant to state the requirement, whereas 7.20.4 p1 is meant to be read as "integer-valued constant", or something along those lines. Note also: * The term "integer constant" is used in some other places in the Standard where it is meant in the usual sense rather than the term defined in 6.4.4.1. For example, 6.5.3.4 p3: "The alignof operator yields the alignment requirement of its operand type. The result is an integer constant." * When the specific 6.4.4.1 meaning of "integer constant" is intended, this is called out explicitly also in some other places in the Standard. For example, 7.22.1.4 p3: "If the value of base is zero, the expected form of the subject sequence is that of an integer constant as described in 6.4.4.1, [...]" Taking all these together it seems pretty convincing that "integer constant expression" is what was intended.