is 0xE-2 a valid expression?

[Tim Rentsch]

Or 0b11001001. Or 123_456_789.


Note also that the standard allows additional forms of constant
expressions, not just constants, potentially permitting things like:

const int x = 2;
const int y = sqrt(2.0);
x + y; /* implementation-defined constant expression */

Still, I'm not sure this isn't already covered by the general
permission to provide extensions.

Presumably the difference is that extensions could allow
additional forms to be accepted, but could not define additional
forms as being constant expressions, any more than an extension
could define some nonsense input as not having a syntax error.

 

[Seebs]

Really? I run gcc using -ansi -pedantic or -std=c99 -pedantic
basically all the time.

Even that is, quite possibly, not a strictly-conforming mode. It depends;
for quite a while, on many implementations I used, that didn't take away
the POSIXy stuff.

I don't see any text in the Standard that indicates it takes this
position. As a personal reaction I might agree, but I don't see
where the Standard either requires it or expects it.

Look at the definition of implementation defined. You may accept additional
implementation-defined constants. If they aren't defined, then they aren't
covered.

I don't see anything in the Standard that requires implementations
to document other forms of constant expressions that they accept.

The term "implementation-defined".

I think if you look again you will see that accepting other
forms of constant expressions is not implementation-defined
behavior.

.... oh.

In that case, nevermind.

-s

 

[Keith Thompson]

Presumably the difference is that extensions could allow
additional forms to be accepted, but could not define additional
forms as being constant expressions, any more than an extension
could define some nonsense input as not having a syntax error.

Ok, here's a concrete example. Suppose an implementation provides an
additional form of constant expression. Specifically, if an object
is declared "const" with an initializer that's a constant expression,
then the name of that object is itself a constant expression.

Then does this program:

int main(void)
{
const int x = 1;
switch (1) {
case x: break;
}
return 0;
}

require a diagnostic?

I would *like* the answer to be yes, because the program is not
portable and could be rejected by a conforming implementation; my
compiler should be required to warn me about that if I ask it to.
But I think the answer is no.

On the other hand, I still think the explicit permission to permit
additional definitions of main is redundant, since the behavior
when using an unsupported definition of main is undefined anyway.

 

[Tim Rentsch]

Even that is, quite possibly, not a strictly-conforming mode. It depends;
for quite a while, on many implementations I used, that didn't take away
the POSIXy stuff.

I believe it is in the sense that it issues a diagnostic for all
cases where the Standard requires a diagnostic. (Or more
precisely, that the people who wrote gcc intend that it issue a
diagnostic in all cases where the Standard requires a diagnostic.)
Certainly in the implementations I'm used to, invoking gcc in this
mode excludes POSIXy stuff (which I keep being reminded of as
I look for the magic restricted identifier to #define to get
it back again).

You're right that this isn't the same as complaining about programs
that aren't strictly conforming, even just that subset of not
strictly conforming that are easily detectable at compile time,
and that distinction can be important. (Learning about the
particular distinctions has been useful for me, so let me say
thank you for making the comment.)

<ot topic=hypenation>
A phrase like "strictly conforming mode" doesn't need a hyphen,
because "strictly" is an adverb, which means the only thing
it can modify is the adjective "conforming". Since there is
no ambiguity, standard usage is to write it without a hyphen.
</ot>

 

[Tim Rentsch]

Ok, here's a concrete example. Suppose an implementation provides an
additional form of constant expression. Specifically, if an object
is declared "const" with an initializer that's a constant expression,
then the name of that object is itself a constant expression.

Then does this program:

int main(void)
{
const int x = 1;
switch (1) {
case x: break;
}
return 0;
}

require a diagnostic?

I would *like* the answer to be yes, because the program is not
portable and could be rejected by a conforming implementation; my
compiler should be required to warn me about that if I ask it to.
But I think the answer is no.

I agree, I think the answer is no.

On the other hand, I still think the explicit permission to permit
additional definitions of main is redundant, since the behavior
when using an unsupported definition of main is undefined anyway.

Here's what I think the (or a?) difference is. Any behavior specified
as implementation-defined must be documented no matter what decision
is made. An extension must be documented only if it is present.
Since additional forms of 'main()' are implementation-defined, if an
implementation doesn't define any other forms it still must document
that decision, eg, "No other forms of main() are accepted." That
wouldn't be required if other forms of main() were just extensions.

 

[Nobody]

"Hexadecimal constant cannot have exponent".

Oh, but a hexadecimal constant *can* have an exponent; it just has to use
"p" or "P" instead of "e" or "E".

 

[Keith Thompson]

Oh, but a hexadecimal constant *can* have an exponent; it just has to use
"p" or "P" instead of "e" or "E".

The grammar uses the term "hexadecimal-constant" to refer
only to an *integer* hexadecimal constant, which cannot have
an exponent; a floating-point hexadecimal constant is called
a "floating-hexadecimal-constant". So the message is correct
(assuming "Hexadecimal constant" means "hexadecimal-constant"),
but it could be clearer.

Possibly the message predates the introduction of the
floating-hexadecimal-constant.

(I mentioned this last week.)

 

[Richard Tobin]

Oh, but a hexadecimal constant *can* have an exponent; it just has to use
"p" or "P" instead of "e" or "E".

[/QUOTE]

Possibly the message predates the introduction of the
floating-hexadecimal-constant.

I made up that message in response to Jacob's request. I hadn't
considered hexadecimal floating constants. You could add "integer" to
it for correctness. There's often a tension in error messages between
prefect correctness and conveying the error effectively to the user,
so I wouldn't be bothered by the minor inaccuracy myself.

-- Richard

 

[Keith Thompson]

Possibly the message predates the introduction of the
floating-hexadecimal-constant.

I made up that message in response to Jacob's request. I hadn't
considered hexadecimal floating constants. You could add "integer" to
it for correctness. There's often a tension in error messages between
prefect correctness and conveying the error effectively to the user,
so I wouldn't be bothered by the minor inaccuracy myself.[/QUOTE]

It wouldn't even be an inaccuracy. There's certainly no requirement
for phrases in diagnostics to match the names of non-terminals in
the grammar. Something like:

Hexadecimal integer constant cannot have exponent

would be both clear and correct; "integer constant" does match the
appropriate non-terminal name "integer-constant", and "Hexadecimal"
is simply an English adjective.