Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 09 Sep 2024 18:52:34 -0700
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <86jzfki8bh.fsf@linuxsc.com>
References: <vab101$3er$1@reader1.panix.com> <vbcs65$eabn$1@dont-email.me> <vbekut$1kd24$1@paganini.bofh.team> <vbepcb$q6p2$1@dont-email.me> <vbgb5q$1ruv8$1@paganini.bofh.team> <vbhbbb$1blt4$1@dont-email.me> <vbipp5$24kl5$1@paganini.bofh.team> <vbk0d9$1tajm$1@dont-email.me> <vbkpfc$27l2o$1@paganini.bofh.team> <vbl3am$228vv$1@dont-email.me> <vblfgb$2dkij$1@paganini.bofh.team> <878qw13a40.fsf@nosuchdomain.example.com> <vbll6l$2dpn7$2@paganini.bofh.team> <874j6p34df.fsf@nosuchdomain.example.com> <vbn79l$2g9i6$1@paganini.bofh.team> <vbn9e1$2fqep$1@dont-email.me> <vbnboc$2g0vc$2@dont-email.me> <20240909114553.226@kylheku.com> <vbngrb$2gvrs$1@dont-email.me> <20240909152336.398@kylheku.com> <87r09s1kdj.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 10 Sep 2024 03:52:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2716f454c4dece03d014ce5d7a2dd1ff";
	logging-data="2882743"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/l7Ea0yWliodrHy6gnqXqq6/AITFrVraA="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:fhrbSjUTnJJbywY7pHpZfZrbghE=
	sha1:ZsaVaIAcKPgd3xviAuTvrZsjC9g=
Bytes: 3407

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> I had thought that the standard required support for constants of
> extended integer types wider than int, but the wording seems
> ambiguous at best.
>
> An unsuffixed decimal constant, for example, has a type that is
> the first of int, long int, long long int in which its value can
> be represented.  But:
>
>     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.
>
> The word "may" in that first sentence seems problematic.  It
> implies a choice:  either a decimal integer constant with a value
> of LLONG_MAX+1 is of an extended integer type, or it isn't.  One
> possible interpretation is that such a constant must be of an
> extended integer type if an appropriate type exists.  Another is
> that it may or may not be of an extended integer type at the whim
> of the implementation -- but the standard doesn't say that the
> choice is either implementation-defined or unspecified.  It just
> says "may".

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?