Re: [MinGW-dvlpr] libmingwex.a

[<dan...@ya...>]

 --- Earnie Boyd <ear...@ya...> wrote: > I think this is great,
although I haven't looked at the diff file yet. 

I've found one typo in code already, but only showed up with GCC3.1 C++
testcases. I'm sure there are others.  I definitely need  to start a test
harness. 

> Why don't you create a mingwex branch in CVS, create a snapshot from the
> branch and go from there? 

Why don't I?   Currently, creating branches is outside my CVS comfort zone,
but that means a delay rather than a barrier.  I would prefer doing it on
SF CVS since fewer people will shake their finger at me there if [when] I
get it wrong first time.  If I create branch, do you believe the code will
be sufficiently exercised?

The second point is, that although the main function of this libray is
C-runtime support for new ANSI functions, an important spin-off is that it
will enable  C++ STL support for long-long IO (diabled by configure with
current C runtime)  and some support for wchar classes.  So the sooner it
becomes "official" the sooner that STL support is available in GCC 3.x.

 There will be a need for a -mminimalist (or
> -mstrict-msvc) switch so that a macro can be set to control the
> extentions as well as adding in the library itself.
> 
I don't know about that.  I would prefer always having the lib in the
search path and using  things like -D__NO_ISOCEXT or -D__NO_POSIXEX at
precompile level to control visibility of different parts in headers, like
NO_OLDNAMES works currently.  At least for now.  That would mean fewer
intrusions into GCC sources.  Once dust settles, I would then feel
comfortable putting switches into GCC itself. (Somehow -mstrict-msvc sounds
like a self-contradiction. I would say -mmsvcrt-compat.) 

Should Cygwin apps being included in this discussion?

Danny


http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.