Minimize <iosfwd>

[Zack Weinberg]

On 4/10/07, Benjamin Kosnik <bkoz@redhat.com> wrote:
[...]
> [The __need_mbstate_t hack], however, is problematic.
>
> There's been a serious attempt made to keep system-dependent macros out
> of main include files and into configuration-selected files. I think
> that approach might be best with this, and as an addition I believe
> doing something like a mbstate_t.h that is configuration-selected will
> also simplifiy <cwchar>'s handling of mbstate_t when ndef
> _GLIBCXX_HAVE_MBSTATE_T.

I'd be happy to make changes to the mbstate_t handling, but I'm going
to need more guidance.  I am not sufficiently familiar with the
library organization or configuration logic to understand what you
want done from the above description.

> In addition, this would allow typdefing for mbstate_t in the linux case,
> and thus the removal of the _GLIBCXX_MBSTATE_T macro.

Unless you are proposing to duplicate glibc's definition of the
structure I do not see how you can do that.  glibc <wchar.h> will
continue to assume that it is the one that gets to typedef mbstate_t.

> If you look at the compile-server docs, at the "1.10.4 types defined in
> multiple locations" bit, you'll see more info on this. After two weeks
> spent wrestling with this issue on newlib, glibc, and solaris targets
> I've come to the conclusion that __need_FOO macros should always be
> FOO.h includes

I certainly agree on FOO.h versus __need_FOO - in the dreaded
alternative universe where I have to maintain glibc, it is what I
would be doing - but, um, compile server?  I thought that was an
ex-parrot.

zw