search for: init_file_internal_

...ring would definitely be a nice change for the Windows frontend. diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c index 6f46d78..bd95634 100644 --- a/src/libFLAC/stream_encoder.c +++ b/src/libFLAC/stream_encoder.c @@ -1288,6 +1288,8 @@ static FLAC__StreamEncoderInitStatus init_FILE_internal_( if(file == stdout) file = get_binary_stdout_(); /* just to be safe */ + setvbuf(file, NULL, _IOFBF, 10*1024*1024); /* 10MB output buffer to help reduce disk fragmentation */ + encoder->private_->file = file; encoder->private_->progress_callback = progr...

...ut the intricates of Win32, but why not prefer this for clarity: diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c index 203a271..0394c26 100644 --- a/src/libFLAC/stream_encoder.c +++ b/src/libFLAC/stream_encoder.c @@ -1330,7 +1330,8 @@ static FLAC__StreamEncoderInitStatus init_FILE_internal_( * Windows can suffer quite badly from disk fragmentation. This can be * reduced significantly by setting the output buffer size to be 10MB. */ - setvbuf(file, NULL, _IOFBF, 10*1024*1024); + if(file != stdout) + setvbuf(file, NULL, _IOFBF, 1...

lvqcl wrote: > Then IMHO all three build systems (configure && make, Makefile.lite > and MSVC) should be synchronized with each other +1 > TO ERIK: > > I have some patches, but they either modify MSVC .vcxproj files, > or win_utf8_io.c/.h, so they conflict with patches from Evan Ramos. > So should they be applied? rejected? postponed until after flac 1.3.2? We

...qcl wrote: > all I can suggest > is to apply this patch, then fix issues if they'll happen after > this. But seriously, as a matter of fact win_utf8_io is a part of libFLAC. Functions from libFLAC call functions from win_utf8_io... For example: FLAC__stream_decoder_init_file() calls init_file_internal_() that calls flac_fopen() that is defined as fopen_utf8(). Currently functions in win_utf8_io.c are a compatibility layer for libFLAC. I can't see reasons not to move win_utf8_io.c into libFLAC.

...ect) bytes in 1 blocks are definitely lost in loss record 5 of 5 ==30495== at 0x400522F: calloc (vg_replace_malloc.c:418) ==30495== by 0x4068847: FLAC__stream_decoder_new (stream_decoder.c:284) ==30495== by 0x4074911: init_stream_internal_ (stream_encoder.c:1007) ==30495== by 0x4075A98: init_FILE_internal_ (stream_encoder.c:1221) ==30495== by 0x401EE65: FLAC::Encoder::File::init(char const*) (stream_encoder.cpp:459) ==30495== by 0x401E9FC: FLAC::Encoder::File::init(std::string const&) (stream_encoder.cpp:464) ==30495== by 0x804A300: main (in /home/svandijk/programming/FLACLEAK/a.out) ==3...

...src/libFLAC/metadata_iterators.c:3333: undefined reference to `unlink_utf8' flac/src/libFLAC/metadata_iterators.c:3333: undefined reference to `unlink_utf8' flac/src/libFLAC/metadata_iterators.c:3333: undefined reference to `unlink_utf8' libFLAC.a(stream_decoder.release.o): In function `init_file_internal_': flac/src/libFLAC/stream_decoder.c:609: undefined reference to `fopen_utf8' flac/src/libFLAC/stream_decoder.c:609: undefined reference to `fopen_utf8' include/share/compat.h, #ifdef _WIN32: #define flac_fopen fopen_utf8 #define flac_chmod chmod_utf8 #define flac_utime utime_utf8 #def...

Erik de Castro Lopo wrote: > lvqcl, > > Would you be able to have alook at this one? I think its > Windows related: > > https://sourceforge.net/p/flac/feature-requests/114/ > The relevant changes are <http://git.xiph.org/?p=flac.git;a=commitdiff;h=6a6207b52a86b1d7980a5233e297c0fc948bed7d> and

lvqcl wrote: >>> Win_utf8 stuff should not be included in libflac since it's only to be >>> used by the flac.exe frontend. It is not needed by other programs nor >>> would they benefit from it without doing the extra work of converting >>> their ansi filenames and functions to utf-8. >>> >>>> Version 2 of my patch attached, which fixes