[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW compilation errors with Gnulib wchar.h and wctype.h
From: |
Eli Zaretskii |
Subject: |
Re: MinGW compilation errors with Gnulib wchar.h and wctype.h |
Date: |
Sun, 09 Oct 2016 20:47:38 +0300 |
> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sun, 9 Oct 2016 10:35:14 -0700
>
> Eli Zaretskii wrote:
> > I'm not sure I understand how this is different from what
> > e.g. Gnulib's wchar.h already does. Can you point out the crucial
> > differences?
>
> Ah, I didn't look at lib/wchar.in.h. Yes, it's already doing that, with a
> complicated ifdef that is supposed to work on MinGW. It isn't working for
> you, I
> suppose because MinGW's include-file internals have changed. So, what's
> different about your MinGW's include-file internals?
>
> Maybe you're using a 64-bit MinGW, say? wchar.in.h seems to know only about
> 32-bit.
No, I'm using 32-bit MinGW, just the latest release of their runtime
and headers.
What changed is that now MinGW string.h includes wchar.h, and wchar.h
has a special treatment of that inclusion. Here are the important
parts, indented 2 spaces:
#ifndef _WCHAR_H
#pragma GCC system_header
/* This header declares prototypes for wchar_t string functions, as are
* prescribed by ISO-C, but which MSVC also expects, (in contravention of
* ISO-C prescriptions), to find in <string.h>. To accommodate this MSVC
* anomaly, we make provision for <string.h> to include a selected subset
* of <wchar.h>; thus, we do not immediately define _WCHAR_T...
*/
#ifndef __STRING_H_SOURCED__
/* ...but defer it until we have confirmed that this is NOT inclusion for
* only this subset of <wchar.h> declarations.
*/
#define _WCHAR_H
[...]
#endif /* !__STRING_H_SOURCED__ */
/* This completes the set of declarations which are to be duplicated by
* inclusion of <string.h>; revert the declarative condition, to make it
* specific to <wchar.h> alone.
*/
#endif /* !(RC_INVOKED || (_WCHAR_H && _STRING_H)) */
#if defined _WCHAR_H && ! defined RC_INVOKED
#ifndef __STRICT_ANSI__
typedef wchar_t _Wint_t;
#endif
typedef int mbstate_t;
[...]
As you see, when wchar.h is included from string.h, only part of it is
processed, and that part doesn't include, for example, the definition
of mbstate_t, and all the prototypes of wchar.h functions after that.
What happens in many Gnulib files (for example, dirname-lgpl.c) is
that Gnulib's string.h is included, it includes MinGW string.h, which
includes Gnulib's wchar.h, and that in turn includes MinGW wchar.h.
But because string.h was included, __STRING_H_SOURCED__ is defined,
and MinGW's wchar.h doesn't define mbstate_t. Gnulib's wchar.h
doesn't expect that, and uses mbstate_t after #include_next.
Previously, MinGW string.h didn't include wchar.h, but instead
duplicated the relevant parts. So this problem didn't happen.
- MinGW compilation errors with Gnulib wchar.h and wctype.h, Eli Zaretskii, 2016/10/09
- Re: MinGW compilation errors with Gnulib wchar.h and wctype.h, Paul Eggert, 2016/10/09
- Re: MinGW compilation errors with Gnulib wchar.h and wctype.h, Eli Zaretskii, 2016/10/09
- Re: MinGW compilation errors with Gnulib wchar.h and wctype.h, Paul Eggert, 2016/10/09
- Re: MinGW compilation errors with Gnulib wchar.h and wctype.h,
Eli Zaretskii <=
- Re: MinGW compilation errors with Gnulib wchar.h and wctype.h, Paul Eggert, 2016/10/09
- Re: MinGW compilation errors with Gnulib wchar.h and wctype.h, Eli Zaretskii, 2016/10/10
- Re: MinGW compilation errors with Gnulib wchar.h and wctype.h, Paul Eggert, 2016/10/10
- Re: MinGW compilation errors with Gnulib wchar.h and wctype.h, Eli Zaretskii, 2016/10/10