[PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

Chris Johns chrisj at rtems.org
Thu Sep 17 01:15:25 UTC 2020

On 17/9/20 9:50 am, Joel Sherrill wrote:
> On Wed, Sep 16, 2020, 6:43 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at 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.

I found this....


The "Handling Truncation When It Occurs" section in the blog post is something
worth considering. It seems the return value of call should be checked. That
seems reasonable.


More information about the devel mailing list