In article <87fss3wr6t.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> I think it's a tricky question. I think the language would be cleaner
> if the standard explicitly stated that violating a constraint always
> results in undefined behavior -- or if it explicitly stated that it
> doesn't. (The former is my personal preference.)

I agree. But note that there's this definition:

3.8
constraint
restriction, either syntactic or semantic, by which the exposition of
language elements is to be interpreted

As I understand, if such a restriction is not fulfilled, then there
is no interpretation; hence undefined behavior (or program rejection).

But DR 261 says that if one can do without having to use an
unsatisfied constraint, then this is fine. For instance, 1 / 0
is not regarded as a constant expression, just as a "normal"
expression, because it fails to satisfy constraint 6.6p4 on
constant expressions. (In a context of a required constant
expression, there will be undefined behavior or the program will
be rejected, whether the expression is not regarded as a constant
expression or one just considers the failed constraint.)

> The semantics of floating constants specify that the value is "either
> the nearest representable value, or the larger or smaller representable
> value immediately adjacent to the nearest representable value, chosen in
> an implementation-defined manner". Given that infinities are not
> supported, that would be DBL_MAX or its predecessor. Based on that, I'd
> say that:

> - A diagnostic is required.
> - A compiler may reject the program.
> - If the compiler doesn't reject the program, the value of way_too_big
> must be DBL_MAX or its predecessor. (Making it the predecessor of
> DBL_MAX would be weird but conforming.)

> *Except* that the definition of "constraint" is "restriction, either
> syntactic or semantic, by which the exposition of language elements is
> to be interpreted". I find that rather vague, but it could be
> interpreted to mean that if a constraint is violated, there is no valid
> interpretation of language elements.

Yes, this is rather vague, but I think that this should be regarded
as undefined behavior (but nothing prevents the implementation from
defining the behavior). Note that this would allow an implementation
to leave the variable as uninitialized[*], assuming that if the user
wants to use the program despite the diagnostic, the program will
work perfectly as long as the variable is not used.

[*] A possible justification is that if the user defined a variable
whose initializer doesn't make sense on some plarform, this can
mean that this variable will never be used on such a plarform,
e.g. as being used in dead code only.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

On 11/12/21 6:17 PM, Vincent Lefevre wrote:
> In article <smgu08$3r1$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>> I assume we've been talking about implementations that conform to the C
>> standard, right? Otherwise there's nothing meaningful that can be said.
>
> The issue is more related to (strictly) conforming programs.

It can't be. Strictly conforming programs are prohibited from having
output that depends upon behavior that the standard leaves unspecified.
6.4.4.2p4 identifies what is usually three different possible values for
each floating point constant (four if the constant describes a value
exactly half-way between two consecutive representable values, but only
two if it describes a value larger than DBL_MAX or smaller than -DBL_MAX
on a platform that doesn't support infinities), and leaves it
unspecified which one of those values is chosen. Since that is precisely
the freedom of choice that you're complaining about, we can't be
discussing strictly conforming programs - if your program's output
didn't depend upon which choice was made, you'd have no reason to worry
about which choice was made.

And at this point, I've officially grown weary of this discussion, and
am bowing out.

In article <smn6d8$c92$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 11/12/21 6:17 PM, Vincent Lefevre wrote:
> > In article <smgu08$3r1$1@dont-email.me>,
> > James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> ...
> >> I assume we've been talking about implementations that conform to the C
> >> standard, right? Otherwise there's nothing meaningful that can be said.
> >
> > The issue is more related to (strictly) conforming programs.

> It can't be. Strictly conforming programs are prohibited from having
> output that depends upon behavior that the standard leaves unspecified.

This is not how I interpret the standard. Otherwise there would be
an obvious contradiction with note 3, which uses

#ifdef __STDC_IEC_559__

while the value of __STDC_IEC_559__ is not specified in the standard.

What matters is that the program needs to take every possibility into
account and make sure that the (visible) behavior is the same in each
case. So...

> 6.4.4.2p4 identifies what is usually three different possible values for
> each floating point constant (four if the constant describes a value
> exactly half-way between two consecutive representable values, but only
> two if it describes a value larger than DBL_MAX or smaller than -DBL_MAX
> on a platform that doesn't support infinities), and leaves it
> unspecified which one of those values is chosen.

The program can deal with that in order to get the same behavior in
each case, so that it could be strictly conforming. However, if the
behavior is undefined (assumed as a consequence of the failed
constraint), there is *nothing* that one can do.

That said, since the floating-point accuracy is not specified, can be
extremely low and is not even checkable by the program (so that there
is no possible fallback in case of low accuracy), there is not much
one can do with floating point.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Vincent Lefevre <vincent-news@vinc17.net> writes:

> In article <86wnlg9ey7.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Suppose we have an implementation that does not support
>> infinities, a range of double and long double up to about ten to
>> the 99999, and ask it to translate the following .c file
>>
>> double way_too_big = 1.e1000000;
>>
>> This constant value violates the constraint in 6.4.4. Do you
>> think this .c file (and any program it is part of) has undefined
>> behavior? If so, do you think any constraint violation implies
>> undefined behavior, or just some of them?
>
> I think that constraints are there to define conditions under which
> specifications make sense. Thus, if a constraint is not satisfied,
> behavior is undefined [...]

Suppose again we have an implementation that does not support
infinities and has a range of double and long double up to about
ten to the 99999. Question one: as far as the C standard is
concerned, is the treatment of this .c file

double way_too_big = 1.e1000000;

and of this .c file

#include <math.h>

double way_too_big = INFINITY;

the same in the two cases? (The question is meant to disregard
differences that are purely implementation choices, as for
example possibly labelling one case a "warning" and the other
case an "error".)

Question two: does the C standard require that at least one
diagnostic be issued for each of the above .c files?

Note that both of these are yes/no questions.

On 11/15/21 4:18 AM, Vincent Lefevre wrote:
> In article <smn6d8$c92$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 11/12/21 6:17 PM, Vincent Lefevre wrote:
....
>>> The issue is more related to (strictly) conforming programs.
>
>> It can't be. Strictly conforming programs are prohibited from having
>> output that depends upon behavior that the standard leaves unspecified.
>
> This is not how I interpret the standard.

I don't see how there's room for interpretation: "A strictly conforming
program ... shall not produce output dependent on any unspecified ...
behavior, ..." (4p6).

> Otherwise there would be
> an obvious contradiction with note 3, which uses

>
> #ifdef __STDC_IEC_559__
>
> while the value of __STDC_IEC_559__ is not specified in the standard.
>
> What matters is that the program needs to take every possibility into
> account and make sure that the (visible) behavior is the same in each
> case. So...

The example in that footnote is based upon the fact that it's
unspecified whether the macro FE_UPWARD is #defined in <fenv.h>. The
call to fesetround(FE_UPWARD) would refer to an undeclared identifier if
it wasn't. The technique shown in Footnote 3 ensures that fsetround()
doesn't even get called unless __STDC_IEC_60559_BFP__ is already
#defined, thereby ensuring that FE_UPWARD is #defined, and as a result
the output doesn't change just because that call is made. Note: it would
have been better to write

#ifdef FE_UPWARD
fesetround(FE_UPWARD);
#endif

Implementations that don't fully support IEC 60559 might still support
FE_UPWARD.

The example code in that footnote is, however, rather badly chosen,
because it's pretty nearly impossible to make any meaningful use of
floating point operations without producing output that depends upon
things that are unspecified. While the technique shown in Footnote 3
does prevent the call to fesetround() from being problematic in itself,
any situation where the developer cares about the rounding direction
implies that the output from the program will depend upon how rounding
is performed. If that weren't the case, why bother calling it?

That's even more true of __STD_IEC_60559_BFP__. Any program that does
anything with floating point values other than comparing floating point
constants for relative order might have greatly different output
depending upon whether an implementation conforms to IEC_60599, or takes
maximal advantage of the freedom the standard gives them when
__STDC_IEC_60559_BFP__ is not pre#defined. You can write code that
doesn't care whether LDBL_MAX - LDBL_MIN > LDBL_MIN - LDBL_MAX is true
or false, but only by, for all practical purposes, making no meaningful
use of floating point operations.

>> 6.4.4.2p4 identifies what is usually three different possible values for
>> each floating point constant (four if the constant describes a value
>> exactly half-way between two consecutive representable values, but only
>> two if it describes a value larger than DBL_MAX or smaller than -DBL_MAX
>> on a platform that doesn't support infinities), and leaves it
>> unspecified which one of those values is chosen.
>
> The program can deal with that in order to get the same behavior in
> each case, so that it could be strictly conforming.

Agreed - and if your program were so written, you'd have no cause to
complain about which of the three was chosen. But you are complaining
about the possibility that a different one might be chosen than the one
you think should be.

> ... However, if the
> behavior is undefined (assumed as a consequence of the failed
> constraint), there is *nothing* that one can do.

Yes, but nowhere does the standard specify that violating a constraint
does, in itself, render the behavior undefined. Most constraint
violations do render the behavior undefined "by omission of any explicit
definition of the behavior", but not this one. You might not like the
definition that 6.4.4.2p4 provides, but it does provide one.

> That said, since the floating-point accuracy is not specified, can be
> extremely low and is not even checkable by the program (so that there
> is no possible fallback in case of low accuracy), there is not much
> one can do with floating point.

??? You can check for __STDC_IEC_60559_BFP__; if it's defined, then
pretty much the highest possible accuracy is required.
Are you worried about __STDC_IEC_60559_BFP__ being falsely pre#defined?
Accuracy lower that required by IEC 60559 is pretty easily detected,
unless an implementation takes truly heroic efforts to cover it up. To
render the inaccuracy uncheckable would require almost as much hard work
and ingenuity as producing the right result.

In article <86v90t8l6j.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Suppose again we have an implementation that does not support
> infinities and has a range of double and long double up to about
> ten to the 99999. Question one: as far as the C standard is
> concerned, is the treatment of this .c file

> double way_too_big = 1.e1000000;

> and of this .c file

> #include <math.h>

> double way_too_big = INFINITY;

> the same in the two cases?

IMHO, this is undefined behavior in both cases, due to the
unsatisfied constraint. So, yes.

> Question two: does the C standard require that at least one
> diagnostic be issued for each of the above .c files?

Yes: The constraint is unsatisfied in both cases, so at least one
diagnostic is required in both cases.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

On 11/15/21 6:39 PM, Vincent Lefevre wrote:
> In article <86v90t8l6j.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Suppose again we have an implementation that does not support
>> infinities and has a range of double and long double up to about
>> ten to the 99999. Question one: as far as the C standard is
>> concerned, is the treatment of this .c file
>
>> double way_too_big = 1.e1000000;
>
>> and of this .c file
>
>> #include <math.h>
>
>> double way_too_big = INFINITY;
>
>> the same in the two cases?
>
> IMHO, this is undefined behavior in both cases, due to the
> unsatisfied constraint. So, yes.

So, of the three ways used by the standard to indicate that the behavior
is undefined, which one was used in this case?

"If a "shall" or "shall not" requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is undefined.
Undefined behavior is otherwise indicated in this document by the words
"undefined behavior" or by the omission of any explicit definition of
behavior. There is no difference in emphasis among these three; they all
describe "behavior that is undefined"." (4p2).

If it's a "shall" or an explicit "undefined behavior", please identify
the clause containing those words.

In article <smuc7i$6hq$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 11/15/21 4:18 AM, Vincent Lefevre wrote:
> > In article <smn6d8$c92$1@dont-email.me>,
> > James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> >
> >> On 11/12/21 6:17 PM, Vincent Lefevre wrote:
> ...
> >>> The issue is more related to (strictly) conforming programs.
> >
> >> It can't be. Strictly conforming programs are prohibited from having
> >> output that depends upon behavior that the standard leaves unspecified.
> >
> > This is not how I interpret the standard.

> I don't see how there's room for interpretation: "A strictly conforming
> program ... shall not produce output dependent on any unspecified ...
> behavior, ..." (4p6).

I'm not sure what you intended to mean, but IMHO, the "It can't be."
is wrong based on the unsatisfied constraint and definition 3.8 of
"constraint" (but this should really be clarified).

[...]
> > ... However, if the
> > behavior is undefined (assumed as a consequence of the failed
> > constraint), there is *nothing* that one can do.

> Yes, but nowhere does the standard specify that violating a constraint
> does, in itself, render the behavior undefined. Most constraint
> violations do render the behavior undefined "by omission of any explicit
> definition of the behavior", but not this one. You might not like the
> definition that 6.4.4.2p4 provides, but it does provide one.

But the fact that a restriction is not fulfilled (definition 3.8)
is what matters.

Another example:

6.5.2.2 Function calls

Constraints
[...]
2 If the expression that denotes the called function has a type that
includes a prototype, the number of arguments shall agree with the
number of parameters. [...]

IMHO, if one provides an additional argument, this is undefined
behavior, even though the semantics describe the behavior in this
case.

Another one:

6.5.3.3 Unary arithmetic operators

Constraints
[...]
1 The operand of the unary + or - operator shall have arithmetic type
[...]

Even though the semantics for +X still makes sense for any object type,
IMHO, this is undefined behavior if X does not have an arithmetic type.

It happens that the compilers reject such code. But what if they
chose not to reject it? Would they be forced to use the defined
semantics or be allowed to have some other behavior as an extension?
I would say the latter.

The example 6.5.16.1p6 regards a constraint violation as invalid code.

> > That said, since the floating-point accuracy is not specified, can be
> > extremely low and is not even checkable by the program (so that there
> > is no possible fallback in case of low accuracy), there is not much
> > one can do with floating point.

> ??? You can check for __STDC_IEC_60559_BFP__; if it's defined, then
> pretty much the highest possible accuracy is required.

Indeed, well, almost I think. One should also check that
FLT_EVAL_METHOD is either 0 or 1. Otherwise the accuracy
becomes unknown.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

In article <smuvs5$6qh$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 11/15/21 6:39 PM, Vincent Lefevre wrote:
> > In article <86v90t8l6j.fsf@linuxsc.com>,
> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >
> >> Suppose again we have an implementation that does not support
> >> infinities and has a range of double and long double up to about
> >> ten to the 99999. Question one: as far as the C standard is
> >> concerned, is the treatment of this .c file
> >
> >> double way_too_big = 1.e1000000;
> >
> >> and of this .c file
> >
> >> #include <math.h>
> >
> >> double way_too_big = INFINITY;
> >
> >> the same in the two cases?
> >
> > IMHO, this is undefined behavior in both cases, due to the
> > unsatisfied constraint. So, yes.

> So, of the three ways used by the standard to indicate that the behavior
> is undefined, which one was used in this case?

> "If a "shall" or "shall not" requirement that appears outside of a
> constraint or runtime-constraint is violated, the behavior is undefined.
> Undefined behavior is otherwise indicated in this document by the words
> "undefined behavior" or by the omission of any explicit definition of
> behavior. There is no difference in emphasis among these three; they all
> describe "behavior that is undefined"." (4p2).

Omission of any explicit definition of behavior. There is a constraint
(restriction) that is not satisfied. Thus the code becomes invalid and
nothing gets defined as a consequence. This is like, in math, applying
a theorem where the hypotheses are not satisfied.

I would expect the implementation to reject the code, or accept it
in a way unspecified by the standard (but the implementation could
document what happens, as an extension).

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

In article <20211116011941$1337@zira.vinc17.org>,
Vincent Lefevre <vincent-news@vinc17.net> wrote:

> I would expect the implementation to reject the code, or accept it
> in a way unspecified by the standard (but the implementation could
> document what happens, as an extension).

As a useful example, I would say that an implementation that doesn't
support infinities but has NaNs would be allow to track out-of-range
values to try to emulate infinities (e.g. for safety reasons).

For instance,

INFINITY - INFINITY

could yield NaN instead of 0.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

All,

> I don't see how there's room for interpretation: "A strictly conforming
> program ... shall not produce output dependent on any unspecified ...
> behavior, ..." (4p6).

Indeed.

Now the order of evaluation of binary operators is
unspecified. But this does not mean that all programs containing
at least one binary operator is not strictly conforming.

For instance, the order of evaluation of the two
operands in the following expression-statement is unspecified.
But unless they are volatile qualified the output does
not depend on the unspecified behavior:

x+y;

But in:

a[printf("Hello")]+a[printf(" World")];

the output does depend on the order of evaluation,
and a program containing this code is not strictly conforming.

>> #ifdef __STDC_IEC_559__
>>
>> while the value of __STDC_IEC_559__ is not specified in the standard.

The output of a strictly conforming program does not depend on the
implementation used.

Since the value of __STDC_IEC_559__ depends on the implementation,
its use can produce a program that is not strictly conforming.

ps. This whole discussion has been very interesting.

On 11/15/21 8:28 PM, Vincent Lefevre wrote:
> In article <smuvs5$6qh$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 11/15/21 6:39 PM, Vincent Lefevre wrote:
>>> In article <86v90t8l6j.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Suppose again we have an implementation that does not support
>>>> infinities and has a range of double and long double up to about
>>>> ten to the 99999. Question one: as far as the C standard is
>>>> concerned, is the treatment of this .c file
>>>
>>>> double way_too_big = 1.e1000000;
>>>
>>>> and of this .c file
>>>
>>>> #include <math.h>
>>>
>>>> double way_too_big = INFINITY;
>>>
>>>> the same in the two cases?
>>>
>>> IMHO, this is undefined behavior in both cases, due to the
>>> unsatisfied constraint. So, yes.
>
>> So, of the three ways used by the standard to indicate that the behavior
>> is undefined, which one was used in this case?
>
>> "If a "shall" or "shall not" requirement that appears outside of a
>> constraint or runtime-constraint is violated, the behavior is undefined.
>> Undefined behavior is otherwise indicated in this document by the words
>> "undefined behavior" or by the omission of any explicit definition of
>> behavior. There is no difference in emphasis among these three; they all
>> describe "behavior that is undefined"." (4p2).
>
> Omission of any explicit definition of behavior.

The fact that a constraint is violated does not erase the definition
provided by 6.4.4.2p4, or render it any less applicable.

> ... There is a constraint
> (restriction) that is not satisfied.

Agreed.

> ... Thus the code becomes invalid and
> nothing gets defined as a consequence.

This is, I presume, what makes you think that 6.4.4.2p4 is effectively
erased?

The standard says nothing to that effect. The only meaningful thing it
says is that a diagnostic is required (5.1.1.3p1). I do not consider the
standard's definition of "constraint" to be meaningful: "restriction,
either syntactic or semantic, by which the exposition of language
elements is to be interpreted" (3.8). What that sentence means,if
anything, is not at all clear, but one thing is clear - it says nothing
about what should happen if the restriction is violated. 5.1.1.3p1 is
the only clause that says anything about that issue.
Note: the requirement specified in 5.1.1.3p1 would also be erased, if a
constraint violation is considered to effectively erase unspecified
parts of the rest of the standard. Surely you don't claim that 3.8
specifies which parts get erased?

> I would expect the implementation to reject the code, or accept it
> in a way unspecified by the standard (but the implementation could
> document what happens, as an extension).

While an implementation is not required to accept and translate such
code (that's only required for the "one program"), if it does translate
such code, then (in the absence of any other problems) the resulting
executable must produce the same observable behavior as if such a
constant was given a value of either DBL_MAX or nextdown(DBL_MAX) - any
other result fails to meet the requirements of 6.4.4.2p4.

On 11/15/21 8:17 PM, Vincent Lefevre wrote:
> In article <smuc7i$6hq$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 11/15/21 4:18 AM, Vincent Lefevre wrote:
>>> In article <smn6d8$c92$1@dont-email.me>,
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>
>>>> On 11/12/21 6:17 PM, Vincent Lefevre wrote:
>> ...
>>>>> The issue is more related to (strictly) conforming programs.
>>>
>>>> It can't be. Strictly conforming programs are prohibited from having
>>>> output that depends upon behavior that the standard leaves unspecified.
>>>
>>> This is not how I interpret the standard.
>
>> I don't see how there's room for interpretation: "A strictly conforming
>> program ... shall not produce output dependent on any unspecified ...
>> behavior, ..." (4p6).
>
> I'm not sure what you intended to mean, but IMHO, the "It can't be."
> is wrong based on the unsatisfied constraint and definition 3.8 of
> "constraint" (but this should really be clarified).

I said that this issue cannot be "related to (strictly) conforming
programs". This issue can't come up in strictly conforming programs, nor
does the way in which this issue might be resolved have any effect on
whether a program qualifies as strictly conforming. Not only is there
inherently a constraint violation, but the value of such a constant
would be unspecified even if there were no constraint, and the only
reason to care about which value is selected by the implementation would
be if the value affects the observable behavior of your program, which
would mean that it's not strictly conforming.

....
>>> That said, since the floating-point accuracy is not specified, can be
>>> extremely low and is not even checkable by the program (so that there
>>> is no possible fallback in case of low accuracy), there is not much
>>> one can do with floating point.
>
>> ??? You can check for __STDC_IEC_60559_BFP__; if it's defined, then
>> pretty much the highest possible accuracy is required.
>
> Indeed, well, almost I think. One should also check that
> FLT_EVAL_METHOD is either 0 or 1. Otherwise the accuracy
> becomes unknown.

A value of 2 tells you that the implementation will evaluate "all
operations and constants to the range and precision of the long double
type", which is pretty specific about what the accuracy is. It has
precisely the same accuracy that it would have had on an otherwise
identical implementation where FLT_EVAL_METHOD == 0, if you explicitly
converted all double operands to long double, and then converted the
final result back to double. Would you consider the accuracy of such
code to be unknown?

A value of -1 leaves some uncertainty about the accuracy. However, the
evaluation format is allowed to have range or precision that is greater
than that of the expression's type. The accuracy of such a type might be
greater than that of the expression's type, but it's not allowed to be
worse. That's far less uncertainty than what is allowed if
__STDC_IEC_60559_BFP__ is NOT pre#defined by the implementation.

On 11/16/21 6:32 AM, Derek Jones wrote:
> All,
>
>> I don't see how there's room for interpretation: "A strictly conforming
>> program ... shall not produce output dependent on any unspecified ...
>> behavior, ..." (4p6).
>
> Indeed.
>
> Now the order of evaluation of binary operators is
> unspecified. But this does not mean that all programs containing
> at least one binary operator is not strictly conforming.
>
> For instance, the order of evaluation of the two
> operands in the following expression-statement is unspecified.
> But unless they are volatile qualified the output does
> not depend on the unspecified behavior:
>
> x+y;
>
> But in:
>
> a[printf("Hello")]+a[printf(" World")];
>
> the output does depend on the order of evaluation,
> and a program containing this code is not strictly conforming.
>
>>> #ifdef __STDC_IEC_559__
>>>
>>> while the value of __STDC_IEC_559__ is not specified in the standard.
>
> The output of a strictly conforming program does not depend on the
> implementation used.
>
> Since the value of __STDC_IEC_559__ depends on the implementation,
> its use can produce a program that is not strictly conforming.

Agreed. But it also can produce program that is strictly conforming,
just like your example of x+y above.

However, given how horrible the accuracy requirements are when
__STDC_IEC_60559_BFP__ is not pre#defined, the only way that a program
could make any meaningful use of floating point and still be strictly
conforming is if it limits such use to comparing floating point
constants for relative order - and even then, that's only true if the
constants are sufficiently far apart in value to guarantee the result of
that comparison.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/15/21 8:28 PM, Vincent Lefevre wrote:
>> In article <smuvs5$6qh$1@dont-email.me>,
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
[...]
>>> "If a "shall" or "shall not" requirement that appears outside of a
>>> constraint or runtime-constraint is violated, the behavior is undefined.
>>> Undefined behavior is otherwise indicated in this document by the words
>>> "undefined behavior" or by the omission of any explicit definition of
>>> behavior. There is no difference in emphasis among these three; they all
>>> describe "behavior that is undefined"." (4p2).
>>
>> Omission of any explicit definition of behavior.
>
> The fact that a constraint is violated does not erase the definition
> provided by 6.4.4.2p4, or render it any less applicable.

I suggest that that may be an open question.

>> ... There is a constraint
>> (restriction) that is not satisfied.
>
> Agreed.
>
>> ... Thus the code becomes invalid and
>> nothing gets defined as a consequence.
>
> This is, I presume, what makes you think that 6.4.4.2p4 is effectively
> erased?
>
> The standard says nothing to that effect. The only meaningful thing it
> says is that a diagnostic is required (5.1.1.3p1). I do not consider the
> standard's definition of "constraint" to be meaningful: "restriction,
> either syntactic or semantic, by which the exposition of language
> elements is to be interpreted" (3.8). What that sentence means,if
> anything, is not at all clear, but one thing is clear - it says nothing
> about what should happen if the restriction is violated. 5.1.1.3p1 is
> the only clause that says anything about that issue.
> Note: the requirement specified in 5.1.1.3p1 would also be erased, if a
> constraint violation is considered to effectively erase unspecified
> parts of the rest of the standard. Surely you don't claim that 3.8
> specifies which parts get erased?

The standard's definition of "constraint" is uncomfortably vague -- but
that doesn't mean I'm comfortable ignoring it.

Given the definition of a "constraint" as a "restriction, either
syntactic or semantic, by which the exposition of language elements is
to be interpreted", it seems to me to be at least plausible that when a
constraint is violated, the "exposition of language elements" cannot be
interpreted.

The implication would be that any program that violates a constraint has
undefined behavior (assuming it survives translation). And yes, I'm
proposing that violating any single constraint makes most of the rest of
the standard moot.

I'm not saying that this is the only way to interpret that wording.
It's vague enough to permit a number of reasonable readings. But I
don't think we can just ignore it.

I'd like to see a future standard settle this one way or the other.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

> I think it's a tricky question. I think the language would be cleaner
> if the standard explicitly stated that violating a constraint always
> results in undefined behavior -- or if it explicitly stated that it
> doesn't. (The former is my personal preference.)

Other language standards use different concepts, and maybe the C
standard could be improved by adopting them.

The Fortran standard, for example, has numbered constraints and
general prohibitions or requirements, denoted by "shall not"
and "shall", respectively.

If a numbered constraint is violated, the compiler has to detect
and report this. If it fails to do so, it's a compiler bug.
This is usually done for things that can easily be checked
at compile time.

If a "shall" or "shall not" directive is violated, then this is
a bug in the program, and quite specifically the programmer's fault.
A compiler may or may not report an error, this is then mostly
a quality of implementation issue, and often a tradeoff with
execution speed.

It's cleaner than what C has, IMHO.

Sorry for the late reply (not much time ATM).

In article <sn0iog$gna$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

[...]
> >> ??? You can check for __STDC_IEC_60559_BFP__; if it's defined, then
> >> pretty much the highest possible accuracy is required.
> >
> > Indeed, well, almost I think. One should also check that
> > FLT_EVAL_METHOD is either 0 or 1. Otherwise the accuracy
> > becomes unknown.

> A value of 2 tells you that the implementation will evaluate "all
> operations and constants to the range and precision of the long double
> type", which is pretty specific about what the accuracy is. It has
> precisely the same accuracy that it would have had on an otherwise
> identical implementation where FLT_EVAL_METHOD == 0, if you explicitly
> converted all double operands to long double, and then converted the
> final result back to double. Would you consider the accuracy of such
> code to be unknown?

Simply because the accuracy of long double is unknown and may be lower
than the one of float. Annex F says for long double:

F.2 Types
[...]
The long double type matches an IEC 60559 extended format,363) else
a non-IEC 60559 extended format, else the IEC 60559 double format.

Any non-IEC 60559 extended format used for the long double type
shall have more precision than IEC 60559 double and at least the
range of IEC 60559 double.364) The value of FLT_ROUNDS applies to
all IEC 60559 types supported by the implementation, but need not
apply to non-IEC 60559 types.

Just consider a non-IEC 60559 extended format. Note that the standard
says that it shall have more *precision* than IEC 60559 double, but
does not say anything about accuracy.

> A value of -1 leaves some uncertainty about the accuracy. However, the
> evaluation format is allowed to have range or precision that is greater
> than that of the expression's type. The accuracy of such a type might be
> greater than that of the expression's type, but it's not allowed to be
> worse.

I don't see where the standard says that it's not allowed to be worse.
One just has:

5.2.4.2.2 Characteristics of floating types <float.h>
[...]
6 The accuracy of the floating-point operations (+, -, *, /) and
of the library functions in <math.h> and <complex.h> that return
floating-point results is implementation-defined, as is the
accuracy of the conversion between floating-point internal
representations and string representations performed by the
library functions in <stdio.h>, <stdlib.h>, and <wchar.h>. The
implementation may state that the accuracy is unknown.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

In article <87pmqzv64t.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> The standard's definition of "constraint" is uncomfortably vague -- but
> that doesn't mean I'm comfortable ignoring it.

> Given the definition of a "constraint" as a "restriction, either
> syntactic or semantic, by which the exposition of language elements is
> to be interpreted", it seems to me to be at least plausible that when a
> constraint is violated, the "exposition of language elements" cannot be
> interpreted.

DR 261[*] goes in this way, IMHO. Here, the constraint on constant
expressions is used to determine whether an expression may be
regarded as a constant expression or not. Thus, if the constraint
is not matched, then the expression is not a constant expression,
and what falls under this constraint does not apply.

Note that the Committee Response says "valid interpretation of the
code", i.e. if the requirements of a constraint are not met, then
there is no "valid interpretation of the code".

[*] http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_261.htm

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>
> [...]
>
>>> Shouldn't the standard by changed to make INFINITY conditionally
>>> defined (if not required to expand to a true infinity)? [...]
>>
>> To me it seems better for INFINITY to be defined as it is rather
>> than being conditionally defined. If what is needed is really an
>> infinite value, just write INFINITY and the code either works or
>> compiling it gives a diagnostic. If what is needed is just a very
>> large value, write HUGE_VAL (or HUGE_VALF or HUGE_VALL, depending)
>> and the code works whether infinite floating-point values are
>> supported or not. If it's important that infinite values be
>> supported but we don't want to risk a compilation failure, use
>> HUGE_VAL combined with an assertion
>>
>> assert( HUGE_VAL == HUGE_VAL/2 );
>>
>> Alternatively, use INFINITY only in one small .c file, and give
>> other sources a make dependency for a successful compilation
>> (with of course a -pedantic-errors option) of that .c file. I
>> don't see that having INFINITY be conditionally defined buys
>> anything, except to more or less force use of #if/#else/#endif
>> blocks in the preprocessor. I don't mind using the preprocessor
>> when there is a good reason to do so, but here I don't see one.
>
> I don't see how that's better than conditionally defining INFINITY.

It's better only in the sense that it works with the existing
C standards, and may give acceptable results in practice.

Vincent Lefevre <vincent-news@vinc17.net> writes:

> In article <86sfxbpm9d.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> To me it seems better for INFINITY to be defined as it is rather
>> than being conditionally defined. If what is needed is really an
>> infinite value, just write INFINITY and the code either works or
>> compiling it gives a diagnostic.
>
> diagnostic and undefined behavior. [...]

Not everyone agrees with this conclusion.

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

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 10/9/21 4:17 PM, Vincent Lefevre wrote:
>>
>>> In article <86wnmoov7c.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> What occurs is defined behavior and (for implementations that do
>>>> not have the needed value for infinity) violates a constraint. A
>>>> diagnostic must be produced.
>>>
>>> If this is defined behavior, where is the result of an overflow
>>> defined by the standard? (I can see only 7.12.1p5, but this is
>>> for math functions; here, this is a constant that overflows.)
>>
>> "For decimal floating constants, and also for hexadecimal floating
>> constants when FLT_RADIX is not a power of 2, the result is either
>> the nearest representable value, or the larger or smaller
>> representable value immediately adjacent to the nearest
>> representable value, chosen in an implementation-defined manner.
>> For hexadecimal floating constants when FLT_RADIX is a power of 2,
>> the result is correctly rounded." (6.4.4.2p3)
>>
>> In the case of overflow, for a type that cannot represent infinity,
>> there is only one "nearest representable value", which is DBL_MAX.
>
> But does that apply when a constraint is violated?
>
> 6.4.4p2, a constraint, says:
>
> Each constant shall have a type and the value of a constant shall be
> in the range of representable values for its type.
>
> A "constraint", aside from triggering a required diagnostic, is a
> "restriction, either syntactic or semantic, by which the exposition
> of language elements is to be interpreted",

Note that the C standard uses the word "constraint" in at least
two different senses. One is the sense of the definition given
above. Another is the sense of any stated restriction in a
'Constraints' section (and nothing else). AFAICT (I have not
tried to do a thorough search) the second sense never includes
a syntactic restriction.

> which is IMHO a bit vague.

Certainly it is at least ambiguous and subjective.

> My mental model is that if a program violates a constraint and the
> implementation still accepts it (i.e., the required diagnostic is a
> non-fatal warning) the program's behavior is undefined -- but the
> standard doesn't say that. Of course if the implementation rejects
> the program, it has no behavior.

This paragraph uses the word "behavior" in two different senses.
The C standard uses "behavior" to mean behavior in the abstract
machine, or sometimes to mean a description of behavior in the
abstract machine. In this sense the program has behavior whether
it is rejected or not: if it has defined behavior, then that is
the behavior, and if it has undefined behavior then the behavior is
"undefined behavior". The sentence "if the implementation rejects
the program, it has no behavior" uses the word behavior in the
sense of "run-time behavior", which is a different sense than how
"behavior" is used in the C standard. A C program has behavior,
in the sense that the C standard uses the term, whether it is
accepted or not, or even whether it is compiled or not.

> For what it's worth, given this:
>
> double too_big = 1e1000;
>
> gcc, clang, and tcc all print a warning and set too_big to infinity.
> That's obviously valid if the behavior is undefined. I think it's
> also valid if the behavior is defined; the nearest representable
> value is DBL_MAX, and the larger representable value immediately
> adjacent to DBL_MAX is infinity.

Since the implementations listed all have infinities, the value of
the constant is in the range of representable values for its type,
so no constraint is violated, and the behavior is always defined.

> It doesn't seem to me to be particularly useful to say that a
> program can be rejected, but its behavior is defined if the
> implementation chooses not to reject it.

Such cases occur often. Consider an implementation where SIZE_MAX
is 4294967295. If translating a program that has a declaration

static char blah[3221225472];

then the implementation is free to reject it, but the behavior is
defined whether the implementation accepts the program or rejects
it. Behavior is a property of the program, not the implementation.

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

[ is a constraint violation always undefined behavior? ]

> [...] one possible interpretation of the phrase "a restriction
> ... by which the exposition of language elements is to be
> interpreted" could be that if the constraint is violated, there
> is no meaningful interpretation. Or to put it another way,
> that the semantic description applies only if all constraints
> are satisfied.
>
> I've searched for the word "constraint" in the C89 and C99
> Rationale documents. They were not helpful.
>
> I am admittedly trying to read into the standard what I think
> it *should* say. A rule that constraint violations cause
> undefined behavior would, if nothing else, make the standard a
> bit simpler.

Note that constraint violations are not undefined behavior in a
strict literal reading of the definition. Undefined behavior
means there are no restrictions as to what an implemenation may
do, but constraint violations require the implementation to
issue at least one diagnostic, which is not the same as "no
restrictions".

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>
>>> In article <861r3pbbwh.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Vincent Lefevre <vincent-news@vinc17.net> writes:
>>>>
>>>>> In article <86wnmoov7c.fsf@linuxsc.com>,
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>>
>>>>>> What occurs is defined behavior and (for implementations that do
>>>>>> not have the needed value for infinity) violates a constraint.
>>>>>> A diagnostic must be produced.
>>>>>
>>>>> If this is defined behavior, where is the result of an overflow
>>>>> defined by the standard? (I can see only 7.12.1p5, but this is
>>>>> for math functions; here, this is a constant that overflows.)
>>>>
>>>> I'm wondering if you have resolved your original uncertainty
>>>> about the behavior of INFINITY in an implementation that does
>>>> not support infinities?
>>>
>>> I suspect that by saying "overflow", the standard actually meant that
>>> the result is not in the range of representable values. This is the
>>> only way the footnote "In this case, using INFINITY will violate the
>>> constraint in 6.4.4 and thus require a diagnostic." can make sense
>>> (the constraint in 6.4.4 is about the range, not overflow). But IMHO,
>>> the failing constraint makes the behavior undefined, actually makes
>>> the program erroneous.
>>
>> Suppose we have an implementation that does not support
>> infinities, a range of double and long double up to about ten to
>> the 99999, and ask it to translate the following .c file
>>
>> double way_too_big = 1.e1000000;
>>
>> This constant value violates the constraint in 6.4.4. Do you
>> think this .c file (and any program it is part of) has undefined
>> behavior? If so, do you think any constraint violation implies
>> undefined behavior, or just some of them?
>
> (Jumping in though the question was addressed to someone else.)
>
> I think it's a tricky question. I think the language would be
> cleaner if the standard explicitly stated that violating a
> constraint always results in undefined behavior -- or if it
> explicitly stated that it doesn't. (The former is my personal
> preference.)

Here are some statements that I believe are true:

1. The C standard has no statement that says directly that
constraint violations result in undefined behavior.

2. The definition of "constraint" in the C standard is ambiguous
and does not have a single objective meaning.

3. There are no indications (at least none that I am aware of) in
the C standard, or any other official writing of the WG14 group,
of what meaning is intended by the ISO C group for the question
in question.

> Clearly a compiler is allowed (but not required) to reject a program
> that violates a constraint. If it does so, there is no behavior.

Same comment as I gave in my other recent posting - programs have
behavior, in the sense used in the C standard, regardless of
whether any implementation accepts or rejects them. (The behavior
may be "undefined behavior".)

> So the question is whether the behavior is undefined if the
> implementation chooses not to reject it. (I personally don't see a
> whole lot of value in defining the behavior of code that could have
> been rejected outright.

Again, there are lots of constructs that clearly have defined
behavior, and yet implementations can choose to reject them.

> I'm also not a big fan of the fact that
> required diagnostics don't have to be fatal, but that's not likely
> to change.)

IMO this view is short sighted. Implementations are allowed to
define extensions as long as they are documented and don't change
the meaning of any strictly conforming program. If any required
diagnostic has to be fatal, that would disallow all kinds of
useful extensions.

Speaking just for myself, I would like implementations to provide
an option under which any required diagnostic would result in the
program being rejected. But only an option, and in any case that
is in the area of QOI issues, which the C standard has explicitly
chosen not to address.

> [analysis of possible interpretations of the above code fragment]

My question was only about whether there is undefined behavior.

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

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 11/15/21 8:28 PM, Vincent Lefevre wrote:
>>
>>> In article <smuvs5$6qh$1@dont-email.me>,
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
> [...]
>
>>>> "If a "shall" or "shall not" requirement that appears outside of
>>>> a constraint or runtime-constraint is violated, the behavior is
>>>> undefined. Undefined behavior is otherwise indicated in this
>>>> document by the words "undefined behavior" or by the omission of
>>>> any explicit definition of behavior. There is no difference in
>>>> emphasis among these three; they all describe "behavior that is
>>>> undefined"." (4p2).
>>>
>>> Omission of any explicit definition of behavior.
>>
>> The fact that a constraint is violated does not erase the
>> definition provided by 6.4.4.2p4, or render it any less applicable.
>
> I suggest that that may be an open question.
>
>>> ... There is a constraint
>>> (restriction) that is not satisfied.
>>
>> Agreed.
>>
>>> ... Thus the code becomes invalid and
>>> nothing gets defined as a consequence.
>>
>> This is, I presume, what makes you think that 6.4.4.2p4 is
>> effectively erased?
>>
>> The standard says nothing to that effect. The only meaningful
>> thing it says is that a diagnostic is required (5.1.1.3p1). I do
>> not consider the standard's definition of "constraint" to be
>> meaningful: "restriction, either syntactic or semantic, by which
>> the exposition of language elements is to be interpreted" (3.8).

(Incidental remark: the problem is not that the definition of
constraint is meaningless; the problem is that the meaning
of the definition is ambiguous and subjective (but that's not
the same as meaningless (or "not meaningful")).)

>> What that sentence means,if anything, is not at all clear, but one
>> thing is clear - it says nothing about what should happen if the
>> restriction is violated. 5.1.1.3p1 is the only clause that says
>> anything about that issue. Note: the requirement specified in
>> 5.1.1.3p1 would also be erased, if a constraint violation is
>> considered to effectively erase unspecified parts of the rest of
>> the standard. Surely you don't claim that 3.8 specifies which
>> parts get erased?
>
> The standard's definition of "constraint" is uncomfortably vague
> -- but that doesn't mean I'm comfortable ignoring it.
>
> Given the definition of a "constraint" as a "restriction, either
> syntactic or semantic, by which the exposition of language
> elements is to be interpreted", it seems to me to be at least
> plausible that when a constraint is violated, the "exposition of
> language elements" cannot be interpreted.
>
> The implication would be that any program that violates a constraint
> has undefined behavior (assuming it survives translation). And yes,
> I'm proposing that violating any single constraint makes most of the
> rest of the standard moot.
>
> I'm not saying that this is the only way to interpret that wording.
> It's vague enough to permit a number of reasonable readings. [...]

So you're saying that the meaning of the definition of constraint
is to some extent subjective, ie, reader dependent?

On 1/3/22 3:03 PM, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [ is a constraint violation always undefined behavior? ]
>
>> [...] one possible interpretation of the phrase "a restriction
>> ... by which the exposition of language elements is to be
>> interpreted" could be that if the constraint is violated, there
>> is no meaningful interpretation. Or to put it another way,
>> that the semantic description applies only if all constraints
>> are satisfied.
>>
>> I've searched for the word "constraint" in the C89 and C99
>> Rationale documents. They were not helpful.
>>
>> I am admittedly trying to read into the standard what I think
>> it *should* say. A rule that constraint violations cause
>> undefined behavior would, if nothing else, make the standard a
>> bit simpler.
>
> Note that constraint violations are not undefined behavior in a
> strict literal reading of the definition. Undefined behavior
> means there are no restrictions as to what an implemenation may
> do, but constraint violations require the implementation to
> issue at least one diagnostic, which is not the same as "no
> restrictions".

Although, after issuing that one diagnostic, if the implementation
continues and generates an output program, and that program is run, then
its behavior is explicitly defined to be undefined behavior.