RTEMS | Rework implementation of cpukit/libmisc/stringto (!924)

[Prashant Rahul (@prashantrahul141)]

Prashant Rahul commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/924#note_139775


ya sure. 
I first reverted back just those two files to 56f61c7d. And at that time `stringtofloat` and `stringtodouble` used the old templating macro magic for the implementation. 
I looked up other stringto* methods in the directory (in the current commit) to undertand how they were implemented and tried to make the behaviour as similar to them as possible. 

I also read up man pages for strto* functions  to understand how they handled edge cases and errors. That's when I noticed that strto* functions dont specifically mention anything for the case when the input string is null, it falls back to just setting `errno` to `ERANGE`, which could be implementation dependent but I am not sure about that.
So I thought it would be better to just check it ourselves before passing input to those functions, thus making it consistent. 
And also returning `RTEMS_INVALID_NUMBER` when the actual error is a null string might seem  confusing to the consumers of this api. `RTEMS_INVALID_ADDRESS` seemed a much better fit.

And this change also needs to be reflected on other `stringto*` methods therefore https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/929

I am not sure what exactly you meant by "approach", but is this what you referred to?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/924#note_139775
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260123/d3d3a428/attachment-0001.htm>