search for: flac_fopen

test_streams currently depends on grabbag and (on Windows) on win_utf8_io libs. It depends on win_utf8_io only because it uses flac_fopen() function. It will become to depend on libFLAC when all file functions will be moved from win_utf8_io to libFLAC. Not a big problem, but it is possible to avoid this dependency by replacing flac_fopen() with fopen(). test_streams doesn't open/create files with unicode filenames, so it won...

Brian Willoughby <brianw at audiobanshee.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 22:26:40 +0300: > My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). I REALLY doubt it. Even if such systems exist, there's little reason to support test_streams on the...

Ah, ok. I was thinking along the lines of FLAC__int32, where the intention is to be portable without depending upon any specific system. I assumed that flac_fopen() came from that design pattern. If it's really only a few years old, and not original, then changing it back should be fine. A bigger question might be: how are file opens handled in most flac code? It's probably best for test_streams to be consistent. Brian p.s. You mentioned that fla...

My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). You could simply have the following: #if defined _MSC_VER || defined __MINGW32__ #define flac_fopen fo...

test_streams doesn't create/open files with non-ascii filenames, so there's no need in unicode support. The patch changes flac_fopen() calls to fopen(), and removes dependency of test_streams from win_utf8_io. -------------- next part -------------- A non-text attachment was scrubbed... Name: test_streams.zip Type: application/zip Size: 2445 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/201...

On Mar 17, 2013, at 03:57, LRN wrote: > /me looks at chmod and utime wrappers: > Ah, i knew i've missed something! :) > Also, i didn't consider wildcards (i thought shell was supposed to > handle them...). I believe that shell does handle wildcards on all Unix variants, including OSX. Since Windows does not handle them, I suggest that the main flac code not be littered

On 18.3.2013 12:25, Erik de Castro Lopo wrote: > JonY wrote: > >> Before anyone does anything, see __wgetmainargs >> <http://msdn.microsoft.com/en-us/library/ff770599.aspx>. >> >> It can expand wildcards. Since it already provides argc/argv/env, it is >> more a less a drop-in replacement for the main() arguments. > +1 > > Erik Alright, here's

...ysis_static, replaygain_synthesis_static, utf8_static, win_utf8_io_static Both 'libFLAC_static' and 'libFLAC_dynamic' projects depend (only) on 'win_utf8_io_static'. I tried to remove this dependency and libFLAC_dynamic failed to compile since metadata_iterators.c uses e.g. flac_fopen, which is defined in share/compat.h as fopen_utf8. metadata_iterators.obj : error LNK2001: unresolved external symbol unlink_utf8 metadata_iterators.obj : error LNK2001: unresolved external symbol fopen_utf8 metadata_iterators.obj : error LNK2001: unresolved external symbol utime_utf8...

...ally, there's a code in metaflac/operations_shorthand_vorbiscomment.c and flac/vorbiscomment.c that won't work if get_utf8_argv() failed: ... #ifdef _WIN32 /* everything in UTF-8 already. Must not alter */ ... So, flac.exe calls get_utf8_argv(), then calls encode_file() which uses flac_fopen() itself, and then indirectly calls FLAC__stream_encoder_init_{ogg_}file() from libFLAC. One of the parameters of this function is const char *filename. Since filename is an UTF-8 encoded string, this libFLAC function must call file functions from share/win_utf8_io/win_utf8_io.c. ****** TL;DR:...

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

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

...esn't slip out the door while I'm busy. > Should the following #if defined _MSC_VER || defined __MINGW32__ be simplified to #ifdef WIN32 ? Alternatively _WIN32. Since it's win32 and not something compiler specific. As for the macros: +#define flac_vfprintf vfprintf_utf8 +#define flac_fopen fopen_utf8 +#define flac_stat _stat64_utf8 ... I leave this up for Erik to decide, though I would have preferred not using rename macros at all. Not sure if these were intended: +#include <sys/stat.h> /* for flac_stat() */ +#include <sys/utime.h> /* for flac_utime() */ +#include <i...

...OSIX_C_SOURCE >= 200809L +#include <fcntl.h> +#else #include <sys/types.h> /* some flavors of BSD (like OS X) require this to get time_t */ #include <utime.h> /* for utime() */ #endif +#endif #if defined _MSC_VER # if _MSC_VER >= 1800 @@ -160,11 +164,15 @@ #define flac_fopen fopen #define flac_chmod chmod -#define flac_utime utime #define flac_unlink unlink #define flac_rename rename #define flac_stat stat +#if _POSIX_C_SOURCE >= 200809L +#define flac_utime(a, b) utimensat (AT_FDCWD, a, *b, 0) +#else +#define flac_utime utime +#endif #endif #ifdef _WIN32 d...

...necessary on the > > primary platforms. > > No, the flac code will not be "littered with code that's not necessary > on the primary platforms". > > There will be some windows specific code in a new file, a bunch of > replacements of existing fopen() calls with flac_fopen() (similarly > for chmod and utime) and the main function for the flac and metaflac > executables will have an additional: > > #ifdef _WIN32 > if (!convert_argv_to_utf8(&argc, &argv)) > flac__utils_printf(stderr, 1, "ERROR: yada yada\n&quot...

Janne Hyv?rinen 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 the problem for the >>

...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 #define flac_unlink unlink_utf8 #define flac_rename rename_utf8 #define flac_stat _stat64_utf8 The members of the libFLAC API that result in calls to these functions include FLAC__stream_decoder_init_file, FLAC__stream_decoder_...

...cessary on the >> primary platforms. > > No, the flac code will not be "littered with code that's not necessary > on the primary platforms". > > There will be some windows specific code in a new file, a bunch of > replacements of existing fopen() calls with flac_fopen() (similarly > for chmod and utime) and the main function for the flac and metaflac > executables will have an additional: > > #ifdef _WIN32 > if (!convert_argv_to_utf8(&argc, &argv)) > flac__utils_printf(stderr, 1, "ERROR: yada yada\n"); > #endif...

..._MSC_VER || defined __MINGW32__ > > be simplified to > #ifdef WIN32 > > ? Alternatively _WIN32. Since it's win32 and not something compiler > specific. Indeed. Not sure what I was thinking. > > As for the macros: > +#define flac_vfprintf vfprintf_utf8 > +#define flac_fopen fopen_utf8 > +#define flac_stat _stat64_utf8 > ... > > I leave this up for Erik to decide, though I would have preferred not > using rename macros at all. I think this is the sanest way. Only few #ifdefs instead of wrapper functions filled with them that do essentially nothing on *...