Calling round() inside print() result differs between v2.4.2 and v2.5.0-beta2

[Paraphraser]

Basic Infos

• [Y] This issue complies with the issue POLICY doc.
• [Y] I have read the documentation at readthedocs and the issue is not addressed there.
• [N] I have tested that the issue is present in current master branch (aka latest git). I simply upgraded the IDE to 2.5.2-beta2 and then compared it with 2.4.2 behaviour and observed an unexpected and unwelcome difference.
• [Y] I have searched the issue tracker for a similar issue.
• [N/A] If there is a stack dump, I have decoded it.
• [Y] I have filled out all fields below.

Platform

• Hardware: [ESP8286]
• Core Version: [2.5.0-beta2 & 2.4.2]
• Development Env: [Arduino IDE]
• Operating System: [MacOS]

Settings in IDE

• Module: [Wemos D1 mini r2]
• Flash Mode: [dio - as far as I am aware]
• Flash Size: [4MB/1MB]
• lwip Variant: [v2 Lower Memory]
• Reset Method: [whatever the IDE does at the end of a download]
• Flash Frequency: [no menu item for this - can't answer]
• CPU Frequency: [80Mhz]
• Upload Using: [SERIAL]
• Upload Speed: [921600)

Problem Description

Under version 2.4.2, round() appears to return an integer quantity. Under 2.5.0-beta2, round() appears to return a real quantity. I am inferring this from a change in print() behaviour.

MCVE Sketch

#include <Arduino.h>

void setup() {

    Serial.begin(115200);
    while (!Serial);
    delay(100);
    Serial.println();
    Serial.println();

}

void loop() {

    // wait a while
    delay(1511);

    // precalculate upTime to the nearest second
    unsigned long upTime = round(millis()/1000.0);

    // display upTime with an inline calculation
    Serial.print("Up time: inline = ");
    Serial.print(round(millis()/1000.0));
    Serial.print(", pre-calculated = ");
    Serial.println(upTime);
    
}

Debug Messages

Output from compiling under 2.4.2 libraries. Note ABSENCE of decimal places for "inline =" values. This is the expected behaviour.

Up time: inline = 2, pre-calculated = 2
Up time: inline = 3, pre-calculated = 3
Up time: inline = 5, pre-calculated = 5
Up time: inline = 6, pre-calculated = 6
Up time: inline = 8, pre-calculated = 8
Up time: inline = 9, pre-calculated = 9
Up time: inline = 11, pre-calculated = 11
Up time: inline = 12, pre-calculated = 12
...

Output from compiling under 2.5.0-beta2 libraries. Note PRESENCE of decimal places for "inline =" values. This suggests print() is treating the return value from round() as a real quantity. This is unexpected.

Up time: inline = 2.00, pre-calculated = 2
Up time: inline = 3.00, pre-calculated = 3
Up time: inline = 5.00, pre-calculated = 5
Up time: inline = 6.00, pre-calculated = 6
Up time: inline = 8.00, pre-calculated = 8
Up time: inline = 9.00, pre-calculated = 9
Up time: inline = 11.00, pre-calculated = 11
Up time: inline = 12.00, pre-calculated = 12
...

[penfold42]

If this credible: http://www.cplusplus.com/reference/cmath/round/
“The value of x rounded to the nearest integral (as a floating-point value).”
The current behaviour seems correct.

[penfold42]

Either cast it to an int or specify the precision in print :
https://www.arduino.cc/en/Serial/Print
Serial.println(1.23456, 0) gives "1"

[Makuna]

https://github.com/arduino/Arduino/issues/6098

[devyte]

Arduino is not standard C++, but some sort of language of its own that is based on C++

That makes no sense at all. The reasons behind some of the contents of Arduino.h are other, and some of that explanation hints at it: they didn't have the standard implementation way back when they started out, and by now they've entrenched themselves for historical and backwards compatibility reasons, bugs and all.

Here, we try to stick to the C++ standard, and to standard implementations, because not doing that leads to madness. If other sketches are found to behave differently as a result, those sketches need to be fixed. That's a good thing. It has already happened before, e.g. with abs() => std::abs().

@penfold42 shows that we comply with the cplusplus reference.

Closing as non issue.

[Paraphraser]

Where did "Arduino is not standard C++, but some sort of language of its own that is based on C++" come from? I don't see that anywhere in the thread.

Rather than aiming for brevity, I should probably have gone on to explain what I found most troubling about this change in behaviour.

The header file "... cores/esp8266/Arduino.h" contains this line:

#define round(x)     ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))

The line is the same in both 2.4.2 and 2.5.0-beta2 so it should be clear that the intention of the author(s) was that both implementations should have the same behaviour.

If that #define had disappeared in the v2.5.0-beta2 then it would be clear that the math.h implementation was now in force.

The #define is still present so I don't understand how the behavioural change has come about. If we makers can't rely on reading the code to understand behaviour then I think we are on a very slippery slope.

[devyte]

Sigh, I thought that macro was removed already. Looks like our Arduino.h needs some further cleanup.

The mention comes from the link to issue 6098 in the arduino repo, linked by @Makuna .

I'm reopening to cover the cleanup in Arduino.h .

[Makuna]

I am sorry to hear that "here" we don't stick to the Arduino standard. I don't agree with breaking the Arduino standard as all it leads to is more support issues. There was a reason we had that "fix"/"change", it was to keep compatiblity. Get Arduino to change first, then follow. It seems that they will at some point but they haven't yet.
If you read the link, several other entry level languages have this same broken round method that Arduino stuck to. So entry level developers are used to this and have the expectation. More advanced developers should be able to figure it out and use alternatives, like roundf.
Its sick that even math.h uses macros.