[LLVMdev] Handling of unsafe functions

[Richard Smith]

On Thu, Sep 20, 2012 at 10:13 AM, Chris Lattner <clattner at apple.com> wrote:

>
> On Sep 20, 2012, at 3:01 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>
> > On Wed, Sep 19, 2012 at 3:00 AM, Martinez, Javier E
> > <javier.e.martinez at intel.com> wrote:
> >> We have identified functions in LLVM sources using a static code
> analyzer
> >> which are marked as a “security vulnerability”[1][2]. There has been
> work
> >> already done to address some of them for Linux (e.g. snprintf). We are
> >> attempting to solve this issue in a comprehensive fashion across all
> >> platforms. Most of the functions identified are for manipulating
> strings.
> >> Memcpy is the most commonly used of all these unsecure methods. The
> >> following table lists all these functions are their recommended secure
> >> alternatives.
> >
> > I am strongly opposed to using *_s functions.  The issue is that they
> > are no more "secure" than original functions.  One can still pass the
> > destination buffer length incorrectly, especially if it is not known
> > at compile time and should be computed.
> >
> > I agree with Sean that we should move the code using C strings to LLVM
> > safe data types.
>
> I agree.
>
> >
> > And one more thing: it is interesting that the "unsafe"
> > APFloat::convertToHexString (from your patch) is not used anywhere.
>
> Zap it!  Oh wait, is it used by Clang or something else?


Clang doesn't use it, but LLDB does, with an arbitrary-seeming
256-character buffer. Perhaps we should change it to take an
llvm::SmallVectorImpl<char>, rather than relying on a character buffer
"which must be of sufficient size".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120920/6128c89d/attachment.html>