
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>We discussed this at the last CFP meeting. My thought was that “conversion” in 7.25.2.7 #5 refers to the conversion mentioned in #2 and that #2 would be the right place to add “in the return type of the function”:</div><div>-----</div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;">Then, they attempt to convert the subject sequence to a floating-point number<span style="background-color: rgb(255, 251, 0);"> in the return type of the function</span>, and return the result.</blockquote><div>-----</div><div>If done, the exact same change should be made in the last sentences in #2 in 7.25.2.6 (strtod), 7.33.4.2.2 (wcstod), and 7.33.4.2.3 (wcstodN).</div><div><br></div><div>The result of the rushed discussion was for me to add this to the list as a low priority issue to be addressed when time permitted.</div><div><br></div><div>A further thought: </div><div><br></div><div>C generally speaks of conversion to a result type. We might point out the omission in these cases to the C editor, affirm that conversion to the return type of the function is what is intended, and suggest the aforementioned changes.</div><div><br></div><div>Beyond style, just saying "convert … to a floating-point number" could be misunderstood to be referring to an intermediate result, particularly when converting a subject sequence in the decimal form with strtodN or converting a subject sequence in the hexadecimal form with strtod. One might think it to mean: convert the subject sequence to a floating-point number with whatever range and precision the implementation decides is suitable. Fred suggested in CFP 3602 that it might be (mistakenly) thought to mean: convert to the format given by the evaluation method macro.</div><div><br></div><div><div>Without evidence that this is a problem for users, it’s low priority for CFP. However, it does seem like something the editor would want to fix.</div><div><br></div></div><div>- Jim Thomas</div><br class="Apple-interchange-newline"><div><br><blockquote type="cite"><div>On Sep 24, 2025, at 4:26 PM, Fred Tydeman <tydeman.fred@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr">On Thu, Sep 25, 2025 at 5:13 AM Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net">jaswthomas@sbcglobal.net</a>> wrote:<br></div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>

<br>

> On Sep 17, 2025, at 8:33 PM, Fred J. Tydeman <<a href="mailto:tydeman@tybor.com" target="_blank">tydeman@tybor.com</a>> wrote:<br>

> <br>

> C23: (N3219)<br>

> <br>> 7.24.1.6 The strtodN functions<br>

> <br>

> 5 If the subject sequence has the expected form for a decimal<br>

> floating-point number, the value resulting from the conversion is<br>

> correctly rounded and the coefficient c and the quantum exponent q are<br>

> determined by the rules in 6.4.4.3 for a decimal floating constant of<br>

> decimal type.<br></blockquote><div><br></div><div>Is it worth adding after "correctly rounded"</div><div>(to the return type of the function)</div><div> </div></div></div>

</div></blockquote></div><br></body></html>