search for: converttohexstr

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

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

Hi, I am trying to print a hex value ( 4111999A for 9.1) for a corresponding floating point number. The routine convertToHexString in APFFloat class only prints in C99 Floating point hexagondecimal constant (eg 1.e00000p3). Without writing my own routine, how do I get to print the hexadecimal representation for a floating point value? Sirish -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum --------...

.... 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. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

...tch that replaces the string manipulation functions an > appropriate string object. Please break the patch up into focused chunks, one per logical change. We try to keep all LLVM development as incremental as possible [1]. I recommend fixing a single logical occurrence (such as fixing APFloat::convertToHexString()) and then mailing the patch to llvm-commits. It's likely that the feedback you get from the review of the first patch will help inform future patches and simplify later patch reviews. [1] http://llvm.org/docs/DeveloperPolicy.html#incremental-development > I know both functions can be...

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

Hello, 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