5

[conv.fpint] p2 says

If the value being converted is in the range of values that can be represented but the value cannot be represented exactly, it is an implementation-defined choice of either the next lower or higher representable value.

[intro.abstract] p2 says

Certain aspects and operations of the abstract machine are described in this document as implementation-defined (for example, sizeof(int)). These constitute the parameters of the abstract machine. Each implementation shall include documentation describing its characteristics and behavior in these respects. Such documentation shall define the instance of the abstract machine that corresponds to that implementation (referred to as the “corresponding instance” below).

[intro.abstract] p5 says

A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input. However, if any such execution contains an undefined operation, this document places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation).

Consider that there is an implementation, which cannot represent the value 16777217 exactly in an object of float type, and the choice for such a value can be either 16777216 or 16777218. For all odd times of the evaluation of the conversion, it chooses the lower representable value, and for all even times of evaluation of the conversion, it chooses the higher representable value. Is this a conforming implementation?

float a1 = 16777217; // 16777216
float a2 = 16777217; // 16777218
.
.
.
float a<2n-1> = 16777217; // 16777216
float a<2n> = 16777217; // 16777218

Update:

A resemble case:

sizeof(int);  // 4
sizeof(int);  // 8
.
.
.
sizeof(int);  // 4
sizeof(int);  // 8

For all odd times of the evaluation of sizeof(int), the results are all 4, and for all even times of evaluation of sizeof(int), the results are all 8.

xmh0511
  • 7,010
  • 1
  • 9
  • 36
  • 1
    Your title makes it sound as if the question is whether implementation-defined behavior can be non-deterministic (in the same sense as unspecified behavior), but your example is deterministic (you defined exactly one execution path) and seems to only be concerned with whether the choice can depend on other state of the machine. Which one are you interested in? – user17732522 Jul 11 '22 at 08:58
  • `one of the possible` The possible executions is that the value can be either 16777216 or 16777218. I have this relevant https://stackoverflow.com/questions/64740928/can-two-implementation-defined-identical-expressions-give-different-results/64741372#64741372 – KamilCuk Jul 11 '22 at 08:59
  • @user17732522 I am concerned about whether the result of an operation defined as implementation-defined behavior should be consistent in a program or need not be. – xmh0511 Jul 11 '22 at 09:02
  • [intro.abstract p2 Is implementation-defined behavior can have more than one possible execution](https://github.com/cplusplus/CWG/issues/91) – Jason Jul 11 '22 at 09:03
  • @AnoopRana That is what I wrote. In that issue, it is obviously the intent seems to the results of the same input should all be consistent in a program. – xmh0511 Jul 11 '22 at 09:06
  • @KamilCuk This is our reading of "implementation-defined behavior", however, the standard seems not to intend to mean that(as the link cited by AnoopRana). This is the purpose of why I created this post for discussion. – xmh0511 Jul 12 '22 at 08:55
  • The ratified standard (not some "intent" that is not incorporated into that standard) is the yardstick for correctness of an implementation. If the ratified standards currently specify a bounded set of possibilities and an implementation-defined choice between them, then wording in current standards permit an implementation to make varying choices (e.g. at different times during a single execution of the program). So I consider the comments about "intent" of the standard are a red herring here - at least, until a ratified standard is available which reflects that "intent". – Peter Jul 17 '22 at 02:14

1 Answers1

0

Technically, yes. You already quoted the relevant text so my answer will not include any further quotes. implementation-defined means that the implementation must document the behaviour that it implements.

There is no further constraint on the behaviour than specified in the text you quoted. It would be a quality-of-implementation issue whether the implementation documents a single outcome or a range of outcomes and under what circumstances, etc.

M.M
  • 138,810
  • 21
  • 208
  • 365
  • However, the intent of the standard wants to express the choice should be consistent in a program. see https://github.com/cplusplus/CWG/issues/91 – xmh0511 Jul 11 '22 at 09:04
  • In [intro.abstract]/1 the abstract machine is defined as a "_parameterized [and] nondeterministic_". 2 says that the parametrization is the behavior stated as implementation-defined in the standard (resulting in one specific _corresponding instance_) and 3 says that the non-deterministic part is behavior stated as unspecified behavior in the standard. 5 says that the observable behavior must match one of the possible executions of the _corresponding instance_. It does not seem obvious to me that this allows implementation-defined behavior to include further non-determinism. – user17732522 Jul 11 '22 at 09:09
  • @user17732522 How do you think about this behavior as the parameter *[* For all odd times of the evaluation of the conversion, it chooses the lower representable value, and for all even times of evaluation of the conversion, it chooses the higher representable value. Is this a conforming implementation *]* ? Is it considered parameterized or non-deterministic? – xmh0511 Jul 11 '22 at 09:13
  • @xmh0511 That seems completely deterministic to me. It just can't be decided locally in a program's execution. But I don't see anything in [intro.abstract] requiring such a property. (I think) it only requires the choice to be deterministic for any given program and input. Whether this is an allowed choice for the parametrization would I guess be a different question, certainly doesn't seem like it is intended to be. – user17732522 Jul 11 '22 at 09:19
  • @user17732522 So, you seem to agree that the implementation in the question is a conforming implementation. However, the results of `sizeof(int)` can be similar for this case, you will note, in https://github.com/cplusplus/CWG/issues/91#issuecomment-1179997771, that the intent of implementation-defined behavior actually requires the results of the same input should be consistent in a program. – xmh0511 Jul 11 '22 at 09:24
  • @xmh0511 I am just saying that if you make a rule which for any given program, input and instance of the implementation-defined behavior gives you exactly one choice for the behavior which the machine will follow, then that can't count as non-determinism of the abstract machine and the machine you chose has only one execution path. Whether any possible rule set is allowed as a parameter of the abstract machine or not seems to be a different question to me that I am not sure what the answer is. – user17732522 Jul 11 '22 at 09:32
  • @xmh0511 "_it is an implementation-defined choice of either_" could be read as there being only two possible choices for the parameter of the machine, or it could be one binary parameter for every possible value before conversion or it could be any rule as a function of program and input as above, I am not sure. Also as mentioned in the linked discussion I think it is reasonable that other parts of the standard may constraint the possible parameters further where necessary to keep it consistent. – user17732522 Jul 11 '22 at 09:32
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/246341/discussion-between-xmh0511-and-user17732522). – xmh0511 Jul 11 '22 at 09:35
  • @user17732522 This is the vague part of [intro.abstract]. I have no good idea to clarify this part. You may want to post your opinions to https://github.com/cplusplus/CWG/issues/91, for clarification. – xmh0511 Jul 11 '22 at 09:41