Re: Top 10 most common hard skills listed on resumes...

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> 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 */