similar to: [PATCH] utf8 lib fixes (not win_utf8_io!)

1) Both src/share/Makefile.am and src/share/utf8/Makefile.am have iconvert.h inside EXTRA_DIST, although iconvert.c includes it. Why? 2) What's the purpose of charsetmap.h? It seems that it's not used anywhere.

Erik de Castro Lopo <mle+la at mega-nerd.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 01:47:01 +0300: >> 1) Both src/share/Makefile.am and src/share/utf8/Makefile.am >> have iconvert.h inside EXTRA_DIST, although iconvert.c includes it. >> Why? > > EXTRA_DIST is for files that are not listed elsewhere in the Makefile.am > but which need to end up in the

I'm looking at an issue reported by the Coverity static analyzer. In iconvert() in src/share/utf8/iconvert.c on line 152 there is newbuf = safe_realloc_add_2op_(utfbuf, ...); If the request size is not valid, the function will free utfbuf and return 0. This is followed by goto fail and utfbuf is freed for the second time. A simply fix would be to set utfbuf to 0 if newbuf is 0. However, this

Erik de Castro Lopo wrote: > lvqcl wrote: > >> 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. > > Applied. All good. Thanks. But the 1st patch

Ok, I managed to compile the Ogg and Vorbis libs. Then, after modifying the file audio_out.c as follows: original: #include <dlfcn.h> modified: #include <win32/include/dlfcn.h> I was able to (finally!) compile libao. Then I tried to compile the module vorbis-tools, but uninvited problems came to my party. [...] > /usr/bin/ld: multiple definitions of symbol _getopt >

LRN wrote: > f:/src/mingw-flac/flac-1.2.2-rc1/src/share/utf8/iconvert.c:175:5: > warning: passing argument 2 of 'libiconv' from incompatible pointer > type [enabled by default] > f:\mingw02\mingw-pc-i686\bin\../lib/gcc/mingw32/4.6.2/../../../../include/iconv.h:83:15: > note: expected 'const char **' but argument is of type 'char **' Firstly, what version of

src/share/utf8/utf8.c mentions that "On NT-based windows systems, we could use WideCharToMultiByte()/MultiByteToWideChar(CP_UTF8), but MS doesn't actually have a consistent API across win32". flac/metaflac don't support Win98 since ver. 1.3.0, so it's possible to use system routines to convert to/from UTF-8. I removed all fprintf(stderr...) code from the win32 code

Hi all, I think we're getting close to the first FLAC release in over 4 years. I have tested whats currently in Git on x86, x86_64 and PowerPC Linux and would appreciate reports of successful compiles (and even more importantly any failures) on OSX, Windows and elsewhere. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo

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

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

The patch <https://git.xiph.org/?p=flac.git;a=commitdiff;h=b3c3e2ac4fcac9d9b178ad240976634d52d5eece> removed Makefile.am files from subdirs of src/share, but for some reasom didn't remove src/share/utf8/Makefile.am. This file is not included into release tarballs, so I think it's indeed unnecessary. It's better to remove it than let it bit-rot. -------------- next part

Currently it is required to include share/compat.h before inclusion of share/win_utf8_io.h. That's because of print_console() declaration: its 3rd argument have type 'uint32_t' which is defined in share/compat.h. So share/win_utf8_io.h depends on share/compat.h which in turn includes share/win_utf8_io.h. Not a problem but it's a bit ugly imho. Actually, the 3rd argument of

Janne Hyv?rinen wrote: > Some comments for patch #1, I chose the non-secure versions because they > are faster and produce smaller binary. The functions where these > printings are performed can't in my opinion ever exceed the safety > margin of 32 KB. They print short help and error texts and occasionally > filename, which with APIs is restricted to 260 characters. And you

Some projects/makefiles add both 'include' and 'include/share' to the list of additional include directories. For example, src/share/utf8/utf8.c includes 'include/share/alloc.h' as "share/alloc.h" but 'include/share/utf8.h' as just "utf8.h". Also src/share/replaygain_analysis/replaygain_analysis.c includes "replaygain_analysis.h", not

Hi all, I added -Wmissing-prototypes -Wstrict-prototypes to the CFLAGS and found that there were a number warnings generated. The patch below fixes those warnings and adds the two -W flags to configure.in. Cheers, Erik ----------------------8<----------------------8<---------------------- --- src/metaflac/operations_shorthand.h 1970-01-01 00:00:00 +0000 +++

For better readability the patch is divided by 3 parts. Part #1: for a bit better security replace vsprintf(utmp, format, argptr) with vsnprintf_s(utmp, 32768, _TRUNCATE, format, argptr) Part #2: potential memleak fixed: utf8argv[i] are not freed when utf8argv itself is freed. Part #3: 'if (ret != 0) break;' line seems redundant. -------------- next part -------------- A

lvqcl wrote: > Oops. It seems that vsnprintf_s isn't always available on MinGW platform: > MinGW declares this function only if MINGW_HAS_SECURE_API macro is defined. > That's because WinXP version of msvcrt.dll doesn't contain secure functions > like vsnprintf_s. I thought Micorsoft had recently stopped supporting WinXP. If Micorsoft has stopped supporting it I see no

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 >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.02.2012 14:18, Erik de Castro Lopo wrote: > I ... would appreciate reports of successful compiles (and even > more importantly any failures) on ... Windows ... > 1) I have to update automake version from 1.7 to 1.11. This might be fixable with installing automake-1.7 for mingw, but i haven't bothered with that, and i prefer 1.11

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