similar to: [PATCH] for win_utf8_io.c

Janne Hyv?rinen wrote: > The break that patch #3 removes is there for a reason. If there is an > error in string conversion there's no point in continuing the operation. > All conversions are discarded if something failed so not exiting from > the loop is wasted effort. Here is the current code: ret = 0; for (i=0; i<wargc; i++) { if ((utf8argv[i] =

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 can't feed it longer faulty names either

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

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. > > Maybe it's better to revert vsnprintf_s to vsprintf or to use vnsprintf? Ok, we need to drop

Hi On MSVCRT, wprintf expects that %s is wide char string, but for not MSVCRT, this is not true. When using -D__USE_MINGW_ANSI_STDIO=1 on MINGW, mingw doesn't use MSVCRT. Therefore, compiling on mingw with -D__USE_MINGW_ANSI_STDIO=1 and redirecting stderr to a file, the printing result is corrupt. We should use fputws simply. A patch is attached. -------------- next part

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

Erik de Castro Lopo wrote: > 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,

lvqcl wrote: > Why? We can use vsnprintf_s for MSVS, and vsnprintf for MinGW. > > MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib > or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible > with WinXP. So it is safe to use it in FLAC. Oh, ok. I missed this bit. I know so very little about Windows. However, if you compile

lvqcl wrote: > I wrote a small program that fills a buffer[] with "abcdefghijklmnopqrstuvwxyz\0" > pattern and then tries to write "0123456789" string into it. > It calls either > ret = vsnprintf_s(buffer, buf_size, _TRUNCATE, fmt, va); > or > ret = vsnprintf(buffer, buf_size, fmt, va); <snip> > vsnprintf (MSVC, MinGW): > > buf_size =

Declan Kelly wrote: > On Thu, Sep 18, 2014 at 07:53:12PM +1000, mle+la at mega-nerd.com wrote: > > > I thought Micorsoft had recently stopped supporting WinXP. > > Apparently they changed their mind, due to a large number of users not > upgrading. Security updates, including a monthly malware detection tool, > are still released for XP on Windows Update. <sigh>

just downloaded klibc 0.72 and took a look. first thing i found was that the URL for latest version is out of date: klibc is archived at: ftp://ftp.zytor.com/pub/linux/libs/klibc/ the `libs/' is superfluous. more importantly, this piece of code in klibc/arch/README is wrong: #if STACK_GROWS_UP argc = (int)*argptr--; argv = (char **)argptr; envp = argv-(argc+1); #else argc

On Sep 7, 2010, at 11:30 AM, F van der Meeren wrote: > > > Any ideas on what I am doing wrong here ? > Why not just use something like: const Type *ArgPtr = Type::getInt8PtrTy(Context); const Type *IntPtr = getTargetData().getIntPtrType(Context); and then: const Type *ArgTypes[3] = {ArgPtr, ArgPtr, IntPtr }; Intrinsic::getDeclaration(TheModule,

On 9/21/2014 06:58, lvqcl wrote: > Erik de Castro Lopo wrote: > >>> MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib >>> or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible >>> with WinXP. So it is safe to use it in FLAC. >> >> Oh, ok. I missed this bit. I know so very little about Windows.

I have created the function prototype with the following code: const uintmax_t methodNameSize = 1024; const char methodNameTemplate[] = "llvm.memcpy.p0i%llu.p0i%llu.i%llu"; char methodName[methodNameSize]; // Create the methodName. memset(methodName, 0, methodNameSize); sprintf(methodName, methodNameTemplate, dstSize, srcSize, lengthSize); // Search for the

Hello, I found the reason why "refuse options" is ignored on the server side. When then 5th argument (int val) in the poptOption struct is set to zero, the parsing function poptGetNextOpt() just continues with the next arg, without returning. So check_refuse_options() is simply not called in such cases. The attached patch makes "refuse options" work with checksum and

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

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 :

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

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 >

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: