[LLVMdev] Handling of unsafe functions

[Chris Lattner]

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?

-Chris