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

[Chris Johns]

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....

https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/

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.

Chris