similar to: win_utf8_io, print_console and uint32_t

On 10.4.2013 10:39, Martijn van Beurden wrote: > On 08-04-13 22:00, Janne Hyv?rinen wrote: >> On 8.4.2013 21:38, Janne Hyv?rinen wrote: >>> Friendly people on Hydrogenaudio found some bugs with the Unicode >>> printing code, so I was forced to make adjustments. >>> [...] >> The long line patch is broken and requires much more work, please >> ignore

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 >

First, this dependency exists only on Windows. For obvious reasons such dependency cannot exist on Linux/FreeBSD/OSX/etc. Previous versions (up to 1.2.1) didn't support Unicode filenames on Windows. And then it was decided to add such support. Windows uses UTF-16, where characters have 16-bit wchar_t type. LibFLAC receives strings only via char*. So one way to add Unicode support is to add

I noticed that share/win_utf8_io.h includes windows.h anyway, so another include in win_utf8_io.c is unnecessary. Also, the comment there is incorrect. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_io.patch Type: application/octet-stream Size: 423 bytes Desc: not available Url :

On 8.4.2013 21:38, Janne Hyv?rinen wrote: > Friendly people on Hydrogenaudio found some bugs with the Unicode > printing code, so I was forced to make adjustments. > > While doing testing I noticed that long filenames cause printing bugs > on Linux too. If line length on status printing exceeded console > length it kept printing the same line over and over. > The patch I

The set of four patches that remove dependency of libFLAC on win_utf8_io. Tested only on Windows, with MSVC and MSYS/MinGW (both autotools and makefile.lite) Please review, especially makefile patches, I'm not very familiar with them. -------------- next part -------------- A non-text attachment was scrubbed... Name: 1_sources.zip Type: application/zip Size: 3524 bytes Desc: not available

This patch changes win_utf8_io.c: simplifies *print functions, improves file related functions and prepates to move all file related functions into libFLAC. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_io.patch Type: application/octet-stream Size: 14476 bytes Desc: not available Url :

All MSVC projects that generate .lib files have '_static' suffix in their names; all but win_utf8_io. This patch renames it so that it follows this naming convention. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_static.patch Type: application/octet-stream Size: 9097 bytes Desc: not available Url :

I have been doing some heavy testing with the new FLAC version, and I found that CreateFile function in grabbag had been left out of UTF-8 treatment at some point. This causes re-encoding an existing flac to the same name to break the file if it contains non-ascii characters. Attached patch fixes this. -------------- next part -------------- diff --git a/include/share/win_utf8_io.h

Hi all, I tried building the latest flac.git on Windows with MinGW just today, and got the following build error: (I had to copy-paste this 'by hand', so there might be a few small mistakes) > CCLD utf8/libutf8.la > CC win_utf8_io/win_utf8_io.lo > win_utf8__io/win_utf8_io.c:266:13: error: static declaration > of 'set_filename_utf8' follows

So far I can see three ideal solutions of this issue: 1) Make Unicode support a part of the libFLAC API. In this case there will be no need in separate -lFLAC -lwin_utf8_io options, just -lFLAC will be needed. 2) Remove the dependency between libFLAC and win_utf8_io. In this case win_utf8_io will be linked statically to 1st-party apps, like other libraries from src/share:

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

lvqcl 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

On 10.4.2013 13:06, Janne Hyv?rinen wrote: > On 10.4.2013 10:39, Martijn van Beurden wrote: >> On 08-04-13 22:00, Janne Hyv?rinen wrote: >>> On 8.4.2013 21:38, Janne Hyv?rinen wrote: >>>> Friendly people on Hydrogenaudio found some bugs with the Unicode >>>> printing code, so I was forced to make adjustments. >>>> [...] >>> The long

Hi, This patchet allows a few targets to be disabled when unrequired. The rational is coming from VLC's contrib buildsystem, so far we use make -C to select only some subparts of the available targets. It would be easier and cleaner to use autoconf to do so IMHO. There's an additional patch which fixes the build when building for WinRT/UWP platform, upstreamed from VLC. We have a couple

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

lvqcl wrote: > IIRC libFLAC.a built with "./autogen.sh && ./configure && make" > contains all functions from win_utf8_io. So I think it's possible > to change some Makefile.lite or maybe build/*.mk files so that > there will be no need to add -lwin_utf8_io to -lFLAC. Version 2 of my patch attached, which fixes the problem for the Makefile.lite and Visual

Erik de Castro Lopo wrote: >> 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. > > Ok, lets do it. I just thought that it's more complicated. All *file* functions should really be moved to libFLAC. But other functions should not, because libFLAC doesn't use them. Two of them -

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

Hugo Beauzée-Luyssen wrote: >> configure.ac: Allow the programs to be disabled >> configure.ac: Allow bench to be disabled >> configure.ac: Don't build any tests when they are explicitely disabled >> configure.ac: Allow examples to be disabled >> win_utf8_io: Avoid forbidden functions when building for WinRT/UWP >> >> configure.ac