Re: [Mingw-w64-public] [PATCH 1/2] headers: Allow setting the default __MSVCRT_VERSION__

2017-11-11 Thread Jacek Caban 
I would prefer to have the same names for headers and crt configure 
arguments. Other than that, it looks good to me.



Thanks,

Jacek


On 11/10/17 10:07 PM, Kai Tietz via Mingw-w64-public wrote:

Patch looks ok to me. Jacek any comments?

Thanks
Kai

Am 10.11.2017 21:50 schrieb "Martin Storsjö" :

The CRT parts (especially libmingwex) can't be built with
__MSVCRT_VERSION__=0x1400, so force it to the intended version
there.

Signed-off-by: Martin Storsjö 
---
Updated to take a library name as parameter, which is mapped
to a version, as suggested by Jacek.
---
  mingw-w64-crt/Makefile.am   |  2 +-
  mingw-w64-crt/crt/ucrtbase_compat.c |  1 +
  mingw-w64-headers/configure.ac  | 33 +
  mingw-w64-headers/crt/_mingw.h.in   |  2 +-
  4 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index a90c3ad..9d62c09 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -20,7 +20,7 @@ else
  endif

  AM_CPPFLAGS=$(sysincludes)
-AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00
@ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
+AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00
-D__MSVCRT_VERSION__=0x700 @ADD_C_CXX_WARNING_FLAGS@
@ADD_C_ONLY_WARNING_FLAGS@
  AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
  CPPFLAGSARM32=-mfpu=vfp
  CPPFLAGS32=-m32
diff --git a/mingw-w64-crt/crt/ucrtbase_compat.c
b/mingw-w64-crt/crt/ucrtbase_compat.c
index f955e93..749fc62 100644
--- a/mingw-w64-crt/crt/ucrtbase_compat.c
+++ b/mingw-w64-crt/crt/ucrtbase_compat.c
@@ -9,6 +9,7 @@
  #pragma GCC diagnostic ignored "-Winline"
  #endif

+#undef __MSVCRT_VERSION__
  #define __MSVCRT_VERSION__ 0x1400

  #define vfprintf real_vfprintf
diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac
index 21259d3..d83037e 100644
--- a/mingw-w64-headers/configure.ac
+++ b/mingw-w64-headers/configure.ac
@@ -162,6 +162,39 @@ AC_MSG_RESULT([$with_default_win32_winnt])
  AS_VAR_SET([DEFAULT_WIN32_WINNT],[$with_default_win32_winnt])
  AC_SUBST([DEFAULT_WIN32_WINNT])

+AC_MSG_CHECKING([default msvcrt])
+AC_ARG_WITH([default-msvcrt],
+  [AS_HELP_STRING([--with-default-msvcrt=LIB],
+[Default msvcrt to target (default: msvcrt)])],
+  [],
+  [with_default_msvcrt=msvcrt])
+case $with_default_msvcrt in
+msvcr80*)
+  default_msvcrt_version=0x800
+  ;;
+msvcr90*)
+  default_msvcrt_version=0x900
+  ;;
+msvcr100*)
+  default_msvcrt_version=0x1000
+  ;;
+msvcr110*)
+  default_msvcrt_version=0x1100
+  ;;
+msvcr120*)
+  default_msvcrt_version=0x1200
+  ;;
+ucrt*)
+  default_msvcrt_version=0x1400
+  ;;
+msvcrt|*)
+  default_msvcrt_version=0x700
+  ;;
+esac
+AC_MSG_RESULT([$with_default_msvcrt ($default_msvcrt_version)])
+AS_VAR_SET([DEFAULT_MSVCRT_VERSION],[$default_msvcrt_version])
+AC_SUBST([DEFAULT_MSVCRT_VERSION])
+
  # Checks for typedefs, structures, and compiler characteristics.

  # Checks for library functions.
diff --git a/mingw-w64-headers/crt/_mingw.h.in b/mingw-w64-headers/crt/_
mingw.h.in
index c7b07ed..23fe7d7 100644
--- a/mingw-w64-headers/crt/_mingw.h.in
+++ b/mingw-w64-headers/crt/_mingw.h.in
@@ -217,7 +217,7 @@ limitations in handling dllimport attribute.  */

  #ifndef __MSVCRT_VERSION__
  /*  High byte is the major version, low byte is the minor. */
-# define __MSVCRT_VERSION__ 0x0700
+# define __MSVCRT_VERSION__ @DEFAULT_MSVCRT_VERSION@
  #endif


--
2.7.4



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 2/2] crt: Provide __acrt_iob_func and __p___argv without the __imp_ prefix

2017-11-11 Thread Kai Tietz via Mingw-w64-public 
Patch is Ok.

Thanks
Kai

2017-11-10 10:03 GMT+01:00 Martin Storsjö :
> Some object files in the crt build were previously built with _CRTBLD,
> but not all of them. This lead to these wrappers not defining the
> unprefixed function (since that would cause warnings about mismatched
> dllimport attributes).
>
> Now that we consistently build these files with _CRTBLD, we can
> easily provide the unprefixed version as well.
>
> This fixes linking with lld, which doesn't automatically resolve
> an undefined __acrt_iob_func reference to __imp___acrt_iob_func.
>
> Signed-off-by: Martin Storsjö 
> ---
> This feels like a much better fix than the previous one.
> ---
>  mingw-w64-crt/misc/__p___argv.c | 4 ++--
>  mingw-w64-crt/stdio/acrt_iob_func.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mingw-w64-crt/misc/__p___argv.c b/mingw-w64-crt/misc/__p___argv.c
> index 06b348a..8e1f8ed 100644
> --- a/mingw-w64-crt/misc/__p___argv.c
> +++ b/mingw-w64-crt/misc/__p___argv.c
> @@ -6,10 +6,10 @@
>
>  #include 
>
> -static char ***__cdecl local__p___argv(void)
> +char ***__cdecl __p___argv(void)
>  {
>  return __MINGW_IMP_SYMBOL(__argv);
>  }
>
>  typedef char ***__cdecl (*_f__p___argv)(void);
> -_f__p___argv __MINGW_IMP_SYMBOL(__p___argv) = local__p___argv;
> +_f__p___argv __MINGW_IMP_SYMBOL(__p___argv) = __p___argv;
> diff --git a/mingw-w64-crt/stdio/acrt_iob_func.c 
> b/mingw-w64-crt/stdio/acrt_iob_func.c
> index e8eb077..085a5fa 100644
> --- a/mingw-w64-crt/stdio/acrt_iob_func.c
> +++ b/mingw-w64-crt/stdio/acrt_iob_func.c
> @@ -6,10 +6,10 @@
>
>  #include 
>
> -static FILE *__cdecl local__acrt_iob_func(unsigned index)
> +FILE *__cdecl __acrt_iob_func(unsigned index)
>  {
>  return &(__iob_func()[index]);
>  }
>
>  typedef FILE *__cdecl (*_f__acrt_iob_func)(unsigned index);
> -_f__acrt_iob_func __MINGW_IMP_SYMBOL(__acrt_iob_func) = local__acrt_iob_func;
> +_f__acrt_iob_func __MINGW_IMP_SYMBOL(__acrt_iob_func) = __acrt_iob_func;
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

2017-11-11 Thread Liu Hao 

On 2017/11/11 21:47, Hannes Domani via Mingw-w64-public wrote:

Am Samstag, 11. November 2017, 10:15:00 MEZ hat Liu Hao  
Folgendes geschrieben:


Debugging in assembly exposes indirection through a null pointer in
`mingw-w64-crt/stdio/mingw_wvfscanf.c` around or after line 906:

```
optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (wstr -
(wchar_t *) *pstr), sizeof (wchar_t));`
```


pstr==NULL, so the *pstr part crashes.


No, on the master branch it does not crash.




The CRT libraries of those toolchains were not compiled with debug
information. Further investigation might not be possible.

I am not able to reproducible this problem on master. You might want to
try a newer version and see if the problem still exists.


It doesn't look fixed on master, mingw_wvfscanf.c is the same in v5.x and 
master.

But as far as I can tell this was fixed in mingw_vfscanf in here:
https://sourceforge.net/p/mingw-w64/mailman/message/27912175/
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/72d60c1a06490ec5937e6c620956b167bf0bf329/

There is even the suggestion that mingw_wvfscanf.c might need a similar fix, 
which was never done.



Do it today? I just can't reproduce the problem so I can't test it. Sorry.


--
Best regards,
LH_Mouse


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] headers: Allow setting the default __MSVCRT_VERSION__

2017-11-11 Thread Martin Storsjö 

On Sat, 11 Nov 2017, Jacek Caban wrote:

I would prefer to have the same names for headers and crt configure 
arguments. Other than that, it looks good to me.


Yes, that's probably good. I originally had some thought about why I made 
them different, because what they do is subtly different, but the 
distinction isn't really meaningful.


So I guess --with-default-msvcrt= is the most sensible name for both of 
them then - I'll push it with that name soon.


// Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

2017-11-11 Thread David Lee 
On 11 November 2017 at 21:47, Hannes Domani via Mingw-w64-public
 wrote:
> Am Samstag, 11. November 2017, 10:15:00 MEZ hat Liu Hao  
> Folgendes geschrieben:
>
>> Debugging in assembly exposes indirection through a null pointer in
>> `mingw-w64-crt/stdio/mingw_wvfscanf.c` around or after line 906:
>>
>> ```
>> optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (wstr -
>> (wchar_t *) *pstr), sizeof (wchar_t));`
>> ```
>
> pstr==NULL, so the *pstr part crashes.
>
>> The CRT libraries of those toolchains were not compiled with debug
>> information. Further investigation might not be possible.
>>
>> I am not able to reproducible this problem on master. You might want to
>> try a newer version and see if the problem still exists.
>
> It doesn't look fixed on master, mingw_wvfscanf.c is the same in v5.x and 
> master.
>
> But as far as I can tell this was fixed in mingw_vfscanf in here:
> https://sourceforge.net/p/mingw-w64/mailman/message/27912175/
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/72d60c1a06490ec5937e6c620956b167bf0bf329/
>
> There is even the suggestion that mingw_wvfscanf.c might need a similar fix, 
> which was never done.
>

Looks like the fix was in mingw_vfscanf.c but not in mingw_wvfscanf.c.
optimize_alloc() looks different in each file.

I'll try building a GCC with master mingw-w64, test it and see what happens.

David Lee.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

2017-11-11 Thread Hannes Domani via Mingw-w64-public 
Am Samstag, 11. November 2017, 10:15:00 MEZ hat Liu Hao  
Folgendes geschrieben:

> Debugging in assembly exposes indirection through a null pointer in
> `mingw-w64-crt/stdio/mingw_wvfscanf.c` around or after line 906:
> 
> ```
> optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (wstr -
> (wchar_t *) *pstr), sizeof (wchar_t));`
> ```

pstr==NULL, so the *pstr part crashes.

> The CRT libraries of those toolchains were not compiled with debug
> information. Further investigation might not be possible.
> 
> I am not able to reproducible this problem on master. You might want to
> try a newer version and see if the problem still exists.

It doesn't look fixed on master, mingw_wvfscanf.c is the same in v5.x and 
master.

But as far as I can tell this was fixed in mingw_vfscanf in here:
https://sourceforge.net/p/mingw-w64/mailman/message/27912175/
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/72d60c1a06490ec5937e6c620956b167bf0bf329/

There is even the suggestion that mingw_wvfscanf.c might need a similar fix, 
which was never done.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

2017-11-11 Thread Liu Hao 

On 2017/11/11 12:41, David Lee wrote:

Hello,

Tried to compile and run the following C code on Windows (with
gcc/mingw-w64), and it crashed at the swscanf() call:



#define __USE_MINGW_ANSI_STDIO 1

#include 

int
main(void)
{
 wchar_t buf[] = L"1 2 3";
 wchar_t field[10];

 swscanf(buf, L"%ls", field); // crash
 wprintf(L"%ls\n", field);

 return 0;
}



This is not my original code. The original code is C++ which includes
a C++ header  which indirectly defines __USE_MINGW_ANSI_STDIO
(after multiple levels of includes), so originally I didn't define
this constant myself. At least the code here doesn't have C++
influences.

I assumed that, if __USE_MINGW_ANSI_STDIO is defined to be 1, then the
Microsoft convention of interpreting %s" is suppressed and C99
convention rules. It applies to *printf() so I assumed it applies to
*scanf() as well. Instead the program crashed.

The swscanf() call still crashed with different specifiers: "%s", and "%S"

The compiler used were downloaded from here (5.4.0 and 6.4.0)

https://sourceforge.net/projects/mingw-w64/files/Multilib%20Toolchains%28Targetting%20Win32%20and%20Win64%29/



Regards,

David Lee.



Debugging in assembly exposes indirection through a null pointer in 
`mingw-w64-crt/stdio/mingw_wvfscanf.c` around or after line 906:


```
optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (wstr - 
(wchar_t *) *pstr), sizeof (wchar_t));`

```

The CRT libraries of those toolchains were not compiled with debug 
information. Further investigation might not be possible.


I am not able to reproducible this problem on master. You might want to 
try a newer version and see if the problem still exists.


--
Best regards,
LH_Mouse


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public