user80871: The first time, pow() works.  But inside of a 'for loop', or again afterwards, it doesn't behave !?  (I'm using a Chinese Pro Mini with Arduino 1.8.16)
EDIT
To clarify what I am asking, my question is: "Why does pow() only give the correct answer the first time?"
uint8_t places;
uint8_t temp8;
uint32_t n;

void setup() {
Serial.begin(115200);
}

void loop() {
  places  = 5U;

  n = pow( 10, places);
  Serial.println(n);

  Serial.println("\nHERE'S THE SAME CODE INSIDE OF A 'FOR LOOP'\n");

  for (temp8 = 0; temp8 < places; temp8++)  {
    n = pow( 10, places);
    Serial.println(n);
  }

  Serial.println("\nNOW THE EXACT SAME CODE AS BEFORE GIVES A DIFFERENT RESULT\n");

  n = pow( 10, places);
  Serial.println(n);
 
  while(1){}
}

Here's what the serial monitor shows:

100000
HERE'S THE SAME CODE INSIDE OF A 'FOR LOOP'
99999
99999
99999
99999
99999
NOW THE EXACT SAME CODE AS BEFORE GIVES A DIFFERENT RESULT
99999


user7508: This seems like a case of a confused compiler. More specifically, a
confused optimizer.
On the first occurrence of pow(10, places), the compiler noticed that
places must be equal to 5, and so replaced the expression with its
value. If you disassemble the compiled code, you will notice it calls
Serial.println(100000);

On the following occurrences, the compiler did not notice that places
can not be anything other than 5, so it did not optimize-out the call to
pow(), and got the result 99999.9765625. This is 3 ULPs less than
the exact result, and is consistent with the accuracy you can expect
from pow(). Converting to an integer implicitly rounds towards zero,
hence the printed result: 99999.

80871: <p>The first time, pow() works.  But inside of a 'for loop', or again afterwards, it doesn't behave !?  (I'm using a Chinese Pro Mini with Arduino 1.8.16)</p>
<p><strong>EDIT</strong>
To clarify what I am asking, my question is: &quot;Why does pow() only give the correct answer the first time?&quot;</p>
<pre><code>uint8_t places;
uint8_t temp8;
uint32_t n;

void setup() {
Serial.begin(115200);
}

void loop() {
  places  = 5U;

  n = pow( 10, places);
  Serial.println(n);

  Serial.println(&quot;\nHERE'S THE SAME CODE INSIDE OF A 'FOR LOOP'\n&quot;);

  for (temp8 = 0; temp8 &lt; places; temp8++)  {
    n = pow( 10, places);
    Serial.println(n);
  }

  Serial.println(&quot;\nNOW THE EXACT SAME CODE AS BEFORE GIVES A DIFFERENT RESULT\n&quot;);

  n = pow( 10, places);
  Serial.println(n);
 
  while(1){}
}
</code></pre>
<p>Here's what the serial monitor shows:</p>
<blockquote>
<p>100000</p>
<p>HERE'S THE SAME CODE INSIDE OF A 'FOR LOOP'</p>
<p>99999</p>
<p>99999</p>
<p>99999</p>
<p>99999</p>
<p>99999</p>
<p>NOW THE EXACT SAME CODE AS BEFORE GIVES A DIFFERENT RESULT</p>
<p>99999</p>
</blockquote>
 7508: <p>This seems like a case of a confused compiler. More specifically, a
confused optimizer.</p>
<p>On the first occurrence of <code>pow(10, places)</code>, the compiler noticed that
<code>places</code> must be equal to 5, and so replaced the expression with its
value. If you disassemble the compiled code, you will notice it calls</p>
<pre class="lang-cpp prettyprint-override"><code>Serial.println(100000);
</code></pre>
<p>On the following occurrences, the compiler did not notice that <code>places</code>
can not be anything other than 5, so it did not optimize-out the call to
<code>pow()</code>, and got the result 99999.9765625. This is 3 ULPs less than
the exact result, and is consistent with the accuracy you can expect
from <code>pow()</code>. Converting to an integer implicitly rounds towards zero,
hence the printed result: 99999.</p>
