[LLVMdev] Handling of unsafe functions

Dmitri Gribenko gribozavr at gmail.com
Thu Sep 20 03:01:22 PDT 2012

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.

And one more thing: it is interesting that the "unsafe"
APFloat::convertToHexString (from your patch) is not used anywhere.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the llvm-dev mailing list