Joel Sherrill commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/924#note_139778 There was nothing horrible with the macro based stringto implementation. The developer who changed it just didn't like it. If the macro based version matches the current stringto.h and passes the tests, all is good. But the entire purpose of these helpers is to prevent the callers from duplicating error checks and normalize the return status and API across the data types. That's an indirect way of saying the implementations of the stringto functions should be consistent. RTEMS_INVALID_ADDRESS is a better status for NULL. But get the stringto functions passing the current tests before changing this. As to approach, my suggested approach was to roll back to the last commit before Ralf touched the code. Then update stringto functions to compile with an unmodified version of stringto.h and pass the current tests. I think running coverage reports on it when it works will make sure the tests cover the implementation. Then make any improvements like RTEMS_INVALID_ADDRESS. @gedare Should these be documented in the Classic API Guide? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/924#note_139778 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
