On Wed, Sep 16, 2020, 6:43 PM Chris Johns <chr...@rtems.org> wrote: > On 16/9/20 11:42 pm, Joel Sherrill wrote: > > snprintf() is a safe method and I strongly disagree with the blanket > replacement > > of many safe methods with memcpy(). > > > > Based on what POSIX profiles snprintf() is included in and the safety and > > security requirements those profiles are designed to meet, snprintf() is > > supported by RTOSes that can meet DO-178 Level A. > > > > If the POSIX method being reviewed is in the FACE Safety Base or Safety > Extended > > profile, then it is OK to use and has been used in flight qualified > > applications. And that is a general statement meaning running on any of a > > variety of RTOSes. If the usage is incorrect, let's fix it but blanket > changing > > them is wrong. > > This is really good information, thank you. >
No problem. That doesn't mean you can't do something stupid with it but sprintf() would be discouraged and isn't in those profiles as I recall. > > I see EPICS is reporting similar issues at the moment and looking to work > around > them. > And no one is questioning why? What's the risk? > > Is there a history of why this has been added to compilers as a warning? > I have no idea..snprintf has a length and avoids overwrites. I would suggest that we find a safety or security coding standard that warns about whatever methods this catches. Personally replacing snprintf and strong operations with memmove is semantically wrong. > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
