similar to: Proposal to remove the Visual Studio project files

Ivailo - FILE objects are internal to the C runtime library, they are not system objects like HANDLEs (windows) or file descriptors (unix). This means that if libFLAC has linked against a different C runtime library than your application, then the two FILE objects are incompatible. This isn't just a Windows specific issue either - if libFLAC was compiled against libc and your application

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

I thought about this, and the MSVCRT mismatch also. What annoys me is that I even tried compiling the library myself (with exactly the same Visual Studio 2008 as my application) and the bug didn't change the least. Thank you for your ideas, but unless someone can confirm this, there still remains the possibility that I've made an error somewhere. Also someone with more experience with

Mikael Magnusson wrote: > Jean-Marc Valin wrote: > ... > > I think the amount of Windows crap is getting a bit ridiculous. It always was. I'm just surprised you took so long to realise it :-). > The autotools files can also be used to build Win32 libraries using > mingw32 (preferably cross-compiling on GNU/Linux). It's currently > possible to build static libs. To

Ivailo Karamanolev wrote: > I am currently learning the FLAC C API and had the code working with > FLAC__stream_decoder_init_file. However, since I'd need the Unicode filename > support, I tried _wfopen_s in combination with > FLAC__stream_decoder_init_FILE, however I get a runtime crash as sonn as I > call FLAC__stream_decoder_process_until_end_of_stream. The same code >

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/

I managed to get around it. I used the stream functions and provided my own callbacks for reading and writing. What's strange is that what I've done is just copied the contents of read/write/seek/tell/eof callbacks from the sources to my application and it works just fine, no glitches. When I use the build-in implementation, it just crashes without any reason. It's not a problem to

On 12/3/07, Erik de Castro Lopo <mle+la@mega-nerd.com> wrote: > I just checked and there is nothing needed in configure.ac. > > In the Makefile.am that creates the shared library you need to add > "-no-undefined" to the LDFLAGS variable like this: > > libspeex_la_LDFLAGS = -no-undefined @WHATEVER_WAS_THERE_BEFORE@ Which symbols will it export? I think default

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

On Sun, Feb 5, 2012 at 1:30 AM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/flac-dev > or, via email, send a message with subject or body 'help' to > flac-dev-request at xiph.org

I'd love to fix the .Xcodeproj (which is what they're called now) but I don't have a clue how to, if I were to figure it out would you guys accept it, or is it not worth my time? btw, someone on Windows should get the visual studio files working, it always complains about not finding nasm.exe. On Tue, Apr 30, 2013 at 3:00 PM, <flac-dev-request at xiph.org> wrote: > Send

"Aren't Windows users accustomed to this feature being missing anyway?" I use Mac mostly now, but when I used Windows, now and then I always expected the wildcard to work, it just worked on most things so it was actually a bit of a pain in the ass when it didn't. On Mon, Mar 18, 2013 at 5:35 AM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list

Well, I'm bored, and I hope I'm not getting in the way of anyone, but I was like hell might as well try to make a new Xcode project, although I am using 10.8 with the latest xcode, so I'd have to manually remove that, but there is one serious concern, and that's that header files are being called from 1 directory up from where they are, for example: "share/compat.h"

Largest risks are: 1) encoding errors in a scenario not exercised by the tests 2) violations of the spec that are tolerated by the decoder. I've seen this before with, e.g. x264, where a bug is repeated in the encoder and decoder and hence not caught by any tests. On Apr 26, 2012, at 2:49 AM, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Josh Coalson wrote: > >>

Brian Willoughby wrote: > It makes sense to have the option to return non-zero when the > "compression" fails to "compress." As Erik pointed out, a script > could use the return code to decide to delete the larger FLAC output > file and keep the original input file since it is smaller (and > equally lossless). > > However, I agree that it is

Hi all, I just pushed a commit which fixes a nasty regression in FLAC. https://git.xiph.org/?p=flac.git;a=commit;h=fc360735ce4d1aa88a94bfccdd3bea5bdd19a8d6 > author Erik de Castro Lopo <erikd at mega-nerd.com> > committer Erik de Castro Lopo <erikd at mega-nerd.com> > commit fc360735ce4d1aa88a94bfccdd3bea5bdd19a8d6 > > Fix a regression that severely impacted

Well, I have been away a couple of days, so I don't know if I'm in time, but I reported a memory leak and submitted a patch a couple of months ago. It would be nice if it can make it in. I first reported the leak here: http://lists.xiph.org/pipermail/flac-dev/2011-August/003002.html And the patch is here:

This also causes a warning and looks like it is the wrong #ifdef. ioctl() is only used inside of a '#if !defined __ANDROID__'. Note, this compiler warning was generated when compiling on Mac OSX 10.9 with clang: utils.c:189:6: warning: implicit declaration of function 'ioctl' is invalid in C99 [-Wimplicit-function-declaration] Also, at the moment, TOT does not compile. It

How about using Sourceforge only for the most recent version? It would prevent any possible confusion (or the hassle with SF?s byzantine file interface) and if people are looking for older versions they could always go to http://downloads.xiph.org/releases/flac/. On 29 Nov 2014, at 05:44, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Erik de Castro Lopo wrote: > >>

Erik de Castro Lopo wrote: > > I'd say let's have a release candidate. More often than not, some > > issues turn up due to the exposure to a larger user base and, hence, > > test cases. > > Ok, coming up. Unfortunately I've lost/forgotten my Xiph SVN password. While I get that sorted out for the real release, the pre-releases are here: