Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Top 10 most common hard skills listed on resumes... Date: Mon, 09 Sep 2024 21:39:45 -0700 Organization: None to speak of Lines: 78 Message-ID: <87a5gg15ri.fsf@nosuchdomain.example.com> References: <878qw13a40.fsf@nosuchdomain.example.com> <874j6p34df.fsf@nosuchdomain.example.com> <20240909114553.226@kylheku.com> <20240909152336.398@kylheku.com> <87r09s1kdj.fsf@nosuchdomain.example.com> <86jzfki8bh.fsf@linuxsc.com> <87ed5s1a0q.fsf@nosuchdomain.example.com> <86frq8i31r.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 10 Sep 2024 06:39:45 +0200 (CEST) Injection-Info: dont-email.me; posting-host="29df7bbfeaa4d6ddeb7fdca1349b4e93"; logging-data="2923559"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX180fA4yCs6Odt40wXDwBkJ4" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:dtgytz9gdv1jxHAILIpELohztMo= sha1:Hh8fns3viJM9S4wOUnmegHKh4gY= Xref: csiph.com comp.lang.c:388242 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >> [...] >> >>> Have you tried looking at other uses of the word "may" in the C >>> standard to see if that sheds some light on the question? >> >> If you have any actual insight to offer, feel free to do so. > > Is there some reason you mind my asking a civil question? > > In my view there is no question about the intent here. If > I'm going to try to help you resolve your uncertainty, it > would be helpful to have a better understanding of your > reasoning process. That's why I asked the question. I got the impression that you were providing vague hints and deliberately hiding information. As you know, several other people here have gotten the same impression in similar circumstances. Perhaps that wasn't your intent, but in my opinion it would be to your benefit to be more aware of how you come across. But ok, I'll answer. No, I had not searched the standard for other uses of "may". I started to do so after your post, and the results were not illuminating. The context again: If an integer constant cannot be represented by any type in its list, it may have an extended integer type, if the extended integer type can represent its value. If all of the types in the list for the constant are signed, the extended integer type shall be signed. If all of the types in the list for the constant are unsigned, the extended integer type shall be unsigned. If the list contains both signed and unsigned types, the extended integer type may be signed or unsigned. If an integer constant cannot be represented by any type in its list and has no extended integer type, then the integer constant has no type. Assume for simplicitly an implementation with 64-bit long long and a 128-bit extended integer type (with signed and unsigned variants, but we'll deal only with signed types), and no other extended integer types. (As far as I know no such implementation currently exists.) One plausible rule might be that if an unprefixed decimal integer constant exceeds LLONG_MAX then the type of that constant *is* that extended integer type. (This happens to be the rule that I would strongly prefer.) But if that's the intent, then I find the use of the word "may" misleading. Why use "may" to express a hard requirement (given the preconditions already stated)? Another possible rule might be that a conforming implementation may choose either to give such a constant the extended integer type, or to give it no type (resulting in a constraint violation). That fits with the use of the word "may", which would be giving the implementation the choice. I can't think of a plausible rationale for such a rule, and I would find it quite annoying if an implementation worked that way. And the choice of whether to give such a constant an extended integer type would then be implementation-defined or unspecified, but that's not mentioned in Annex J. My best guess is that the intent was that such a constant is required to have the extended integer type, but that that intent was expressed poorly. I speculate that the wording hasn't been clarifed because no actual implementation is affected. Now, what do *you* think that wording in the standard means? Given an implementation as described above and a decimal integer constant with the value LLONG_MAX+1, does the standard require it to have the extended integer type, or does it not? Would an implementation that provides a 128-bit extended integer type and gives no type to such a constant be non-conforming for that reason? -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */