similar to: [LLVMdev] Handling of unsafe functions

Martinez, Javier E wrote: > 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

I generally disagree with the approach. Generally char* strings aren't recommended for use in LLVM and this kind of string manipulation in LLVM shouldn't be done with the primitive C library functions. The Programmer's Manual gives the preferred types to use for strings [1] and all of them keep track of length. There are also safe routines for creating and formatting strings, such as

Hi Sean, Thanks for the valued feedback. I agree with you that the containers available in LLVM are preferable to char buffers but I want to point out that the proposal doesn't add any new uses of char buffer and merely works with existing ones. Changing existing uses of char buffers to other objects is beyond the scope of this proposal. It makes more sense to do that when changes to code

>From the responses it's pretty clear that the preference is to avoid using C string functions altogether. I've attached at list of calls in Clang/LLVM. The EASY/MEDIUM/DIFFICULT tag is an estimate of the effort to replace the call based on the location of the source buffer. If there are no objections I'll prepare a patch that replaces the string manipulation functions an

On 09/21/2012 05:52 AM, Martinez, Javier E wrote: > The proposal comments have largely centered on the string functions. Do > people feel the same way about memcpy_s? What about those of you > building LLVM on Windows with Visual Studio? Is memcmp_s (or a variant thereof) a win in practice? It covers the case pretty well where you try to copy a dynamically sized buffer to the start

Florian, You have a valid point, the majority of the times memcpy is used correctly and the destination buffer size is redundant information. I think we also agree that there are cases where the correct use of memcpy is not clear cut and the 4-parameter version adds value. I've modified the original proposal to strike the middle of the road. Instead of only providing a 4-parameter version of

> I’ll prepare a patch 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

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 >

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

Hi, Currently the GetClipboardData() function is declared in windows-pr so that it returns a pointer. I guess my reasoning was that I was only worried about dealing with text at the time, so it was the easiest thing to do. But, I''d like to support more formats beyond text, i.e. images. However, this can cause a segfault. If you copy a jpeg image to the clipboard first, for example, and

Hi! I have trouble compiling the flac library using Microsofts free (yes MS gives it away including the optimizing C++ compiler msvc8.0) Visual Studio Express 2005. I get the output shown below. Does anyone have a way to make flac compile in VS 2005? Thanks! Ulrik 1>------ Rebuild All started: Project: replaygain_analysis_static, Configuration: Debug Win32 ------ 1>Deleting

Citeren Frederic BOHE <fbohe-guest op alioth.debian.org>: > Modified: branches/windows_port/include/wincompat.h > ============================================================================== > --- branches/windows_port/include/wincompat.h Wed Jan 26 15:05:16 > 2011 (r2852) > +++ branches/windows_port/include/wincompat.h Wed Jan 26 15:16:09 > 2011 (r2853) > @@

Christoph Terasa wrote: > Since MS refuses to support C99, the common practice is to use either > > sprintf_s: > http://msdn.microsoft.com/en-us/library/ce3zzk1k(v=VS.80).aspx > _snprintf_s: > http://msdn.microsoft.com/de-de/library/f30dzcf6(v=VS.80).aspx > > The former can be used as a drop-in replacement of snprintf via a > define, the latter takes an

Microsoft provides a surprisingly good (but proprietary) API inside strsafe.h. StringCchPrintfA can be substituted for snprintf but the return value is different. A small wrapper function around StringCchPrintfExA could get you enough information to emulate snprintf well. But sprintf_s might be good enough for the limited uses inside flac, as you said. Sent from my iPhone On Mar 14, 2013, at

Hi all, There are a bunch of sprintf calls in the FLAC code base and I'd like to replace them with calls to snprintf but I know that can cause problems with at least some versions of Visual Studio. Whats the current state of play in this regard? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

On Tue, Dec 27, 2016 at 4:13 PM, Teresa Johnson <tejohnson at google.com> wrote: > > On Tue, Dec 27, 2016 at 5:23 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: >> >> After figuring out the fault in the configuration step and rebuilding, >> and then rebuilding again by forcing it with `ninja -k 16`, I managed to >> build everything but 12 ninja

On Tue, Dec 27, 2016 at 8:30 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > On Tue, Dec 27, 2016 at 4:13 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > > > On Tue, Dec 27, 2016 at 5:23 AM, Carsten Mattner < > carstenmattner at gmail.com> wrote: > >> > >> After figuring out the fault in the configuration step and

> On Dec 20, 2016, at 5:49 AM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ​Hi again, Teresa. > > Looks like I had forgotten to report back with success > when finally building 3.9.0 in ThinLTO linker mode > back in October. Sorry about that and thanks for > helping me out. I know how important it is to get > success reports as well, as a

The Wine development release 5.3 is now available. What's new in this release (see below for details): - More work towards Ucrtbase runtime support. - Full support for Unicode normalization. - Improvements in Shell Folders handling. - Various bug fixes. The source is available from the following locations: https://dl.winehq.org/wine/source/5.x/wine-5.3.tar.xz

On 3/14/2013 8:00 AM, Erik de Castro Lopo wrote: > Hi all, > > There are a bunch of sprintf calls in the FLAC code base and I'd like > to replace them with calls to snprintf but I know that can cause > problems with at least some versions of Visual Studio. > > Whats the current state of play in this regard? > > Erik Since MS refuses to support C99, the common