similar to: snprintf and MS Visual Studio

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

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

On Mon, 1 Nov 2004, Morten Ofstad wrote: > with the patches you accepted last week, everything now works with two > one-line modifications. Great! > One is a missing include in a windows specific > platform file and Okay, as Jeff pointed out, this isn't needed, so not applied. > the other is a definition of a symbol I need to trick the linker (as > discussed before)...

We could add the MSVS project files to the repository but I too would like to see a single mechanism for building on all platforms. Someone mentioned using the Boost build system a few weeks ago but I haven't heard anything more on how that effort is going. I also think we can customize our existing makefiles to use the underlying (command oriented) tools under MSVS. We'd still need

src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in "STDDEF.H and other include files".

Hello, with the patches you accepted last week, everything now works with two one-line modifications. One is a missing include in a windows specific platform file and the other is a definition of a symbol I need to trick the linker (as discussed before)... The attached file is the complete diff between my version and the CVS. If you want to put my visual studio project files into the CVS,

Vikram Adve wrote: >> Anyway, if anyone wants the VS project files just contact me. It's >> really a separate thing from the main project so I can see why you're >> reluctant to put it in the CVS. And, as said before, I think most >> windows users would prefer a binary distribution anyway so the ease of >> building the windows version from source is

On Nov 2, 2004, at 8:38 AM, Reid Spencer wrote: > Morten Ofstad wrote: >> Well, actually I'm speaking mostly for myself ;-) I have a front >> end, I want to generate code, all I really need is a llvm.lib and the >> include files that go along with it... I imagine this is quite a >> common scenario, but I might be wrong. > > This is pretty much my usage

On 23.07.2013 18:43, Reid Kleckner wrote: > Is there a problem if the string is not null terminated? If not, you can > snprintf it right into place instead of doing sprintf+mempcy. snprintf always null-terminates (and truncates if there's not enough space). -Nico

Morten Ofstad wrote: > > Well, actually I'm speaking mostly for myself ;-) I have a front end, I > want to generate code, all I really need is a llvm.lib and the include > files that go along with it... I imagine this is quite a common > scenario, but I might be wrong. This is pretty much my usage scenario too, however I expect to be *able* to hack on the source and

Hugo Beauzée-Luyssen <hugo at beauzee.fr> wrote: > --- > src/share/win_utf8_io/win_utf8_io.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/src/share/win_utf8_io/win_utf8_io.c > b/src/share/win_utf8_io/win_utf8_io.c > index c61d27f3..1437b41e 100644 > --- a/src/share/win_utf8_io/win_utf8_io.c > +++ b/src/share/win_utf8_io/win_utf8_io.c >

On Tue, Jul 23, 2013 at 12:48 PM, Nico Rieck <nico.rieck at gmail.com> wrote: > On 23.07.2013 18:43, Reid Kleckner wrote: > >> Is there a problem if the string is not null terminated? If not, you can >> snprintf it right into place instead of doing sprintf+mempcy. >> > > snprintf always null-terminates (and truncates if there's not enough > space).

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

Erik de Castro Lopo wrote: >> because MSVS2005 doesn't provide stdint.h. According to MSDN, >> uintptr_t is defined in "STDDEF.H and other include files". > > Does the rest of FLAC actually support those compilers? Yes. I removed this #include and all projects were successfully built with MSVS 2005 Express. > Is it worth > continuing to support them? * At

Hello, I had some difficulties compiling the current git ( http://git.xiph.org/?p=flac.git;a=commit;h=a7e3705d051bafd1cae90f6605287cc1d9f2a18d ) using the Ubuntu 12.04 supplied MinGW32 cross compiler: I configured the FLAC build with --host=i586-mingw32msvc --target=i586-mingw32msvc --build=i586-linux but ran into several linker problems. Are these options somehow wrong? It worked fine when

There are several links to Windows compiles in the Hydrogenaudio thread for FLAC 1.3.0 at http://www.hydrogenaudio.org/forums/index.php?showtopic=101082 . On Unices or Linuxes building from git should be straightforward enough, or you wait until the distributions/package maintainers catch up. Also, congratulations to the whole development team for reinvigorating FLAC! Christoph On

With current settings, MSVS links debug version of flac.exe (and other .exe and .dll files) with the release version of libogg_static.lib. MSVS issues a "warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library" What's the reason in this setting? What is better: * to change the settings so that MSVS will link debug .exe files with

SimplifyLibCalls.cpp is no longer part of Transforms\IPO and Transforms\Scalar\SimplifyCFG.cpp is renamed to SimplifyCFG.cpp or something to that effect ( I didn't look up the actual checkins ). Having fixed that, I still can't get through the build: Creating library C:\work\s\llvm\win32\\bin\Win32\Debug/opt.lib and object C:\work\s\llvm\win32\\bin\Win32\Debug/opt.exp 1>opt.obj : error

lvqcl wrote: > Why? We can use vsnprintf_s for MSVS, and vsnprintf for MinGW. > > MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib > or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible > with WinXP. So it is safe to use it in FLAC. Oh, ok. I missed this bit. I know so very little about Windows. However, if you compile