Displaying 7 results from an estimated 7 matches for "win_get_console_width".
2017 Jan 06
1
[PATCH 5/5] win_utf8_io: Avoid forbidden functions when building for WinRT/UWP
...lable since MSVS 2012, so build will fail in
older
versions of Visual Studio (and in some older versions of MinGW).
> #include "share/win_utf8_io.h"
> #include "share/windows_unicode_filenames.h"
> @@ -164,11 +165,13 @@ size_t strlen_utf8(const char *str)
> int win_get_console_width(void)
> {
> int width = 80;
> +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
Apparently these preprocessor defines are from winapifamily.h
so it won't work in older MSVS and MinGW.
> CONSOLE_SCREEN_BUFFER_INFO csbi;
> HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE)...
2013 May 15
2
FLAC currently won't compile for Android [bisected]
Felix Homann wrote:
> Here are the warnings I get with 03a9e6064d406e3656afacdbe50e8e47ebfa0de3:
It seems Android sys/param.h doesn't define MIN/MAX.
Could you try to revert this commit on current master (or simply
change line 35 of src/libFLAC/include/private/macros.h back to
#if defined(__GNUC__)
) and recompile? Or possibly bisect 03a9e60..master to find out when
the
2017 Jan 06
8
[PATCH 0/5] Allow multiple targets to be disabled
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
2013 May 23
2
FLAC currently won't compile for Android [bisected]
...- next part --------------
diff --git a/src/flac/utils.c b/src/flac/utils.c
index e908706..6f6382e 100644
--- a/src/flac/utils.c
+++ b/src/flac/utils.c
@@ -171,13 +171,13 @@ static int console_chars_left;
int get_console_width(void)
{
int width = 80;
-#ifdef _WIN32
+#if defined _WIN32
width = win_get_console_width();
#elif defined __EMX__
- int s[2];
- _scrsize (s);
- width = s[0];
-#else
+ int s[2];
+ _scrsize (s);
+ width = s[0];
+#elif !defined __ANDROID__
struct winsize w;
if (ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) != -1) width = w.ws_col;
#endif
2016 Jan 28
2
Lets do a 1.3.2 release
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
2016 Jan 29
2
Lets do a 1.3.2 release
...or
>> 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 - win_get_console_width() and strlen_utf8() - are used only
in src/flac/utils.c. So it makes sense to move these functions into
that file.
But what to do with print functions (printf_utf8, fprintf_utf8, and
vfprintf_utf8) ?
1) keep separate share/win_utf8_io library, with only these three functions in it
2) move them to...
2016 Jan 09
2
About libFLAC -> win_utf8_io dependency
...ted functions from shared libFLAC library,
why not. They won't be officially available to 3rd-party apps,
only to flac/metaflac/etc.
And BTW, flac built with MSYS/MinGW-w64 (with --enable-shared option)
*DOES EXACTLY THIS*: libFLAC-8.dll exports chmod_utf8, CreateFile_utf8 at 28,
fopen_utf8, win_get_console_width, and so on, and flac.exe imports them
from libFLAC-8.dll.