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

Joel Sherrill joel at rtems.org
Wed Sep 16 23:50:43 UTC 2020


On Wed, Sep 16, 2020, 6:43 PM Chris Johns <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.




> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200916/9e356a39/attachment-0001.html>


More information about the devel mailing list