declaration of C function ... conflicts with ... error: previous declaration

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Keith Marshall
On 23 November 2010 09:36, Alois Schlögl <[hidden email]> wrote:

> On 11/22/10 17:31, Keith Marshall wrote:
>> On Saturday 20 November 2010 23:24:52 Tor Lillqvist wrote:
>>
>>> Maybe it would be a good idea if MinGW would split its<io.h>  into
>>> two parts, and including it indirectly through<unistd.h>  would
>>> bypass the Windows-specific APIs? Of course, such a change would
>>> break some existing code. But it would help people in your situation.
>>
>> But, if it would break existing code, why should it be considered any
>> better than the OP working around the issue appropriately in his own
>> source -- i.e. by choosing a more appropriate (portable) name for his
>> own function, so that he avoids the conflict with a publicly documented
>> API on the porting platform he wishes to target?  This, after all, is
>> precisely the sort of issue with which those who port software to any
>> alternative host platform must be prepared to deal, and the preferred
>> solution is invariably to modify the application source, not to hack
>> (break) the tool chain to kludge around any single specific case.
>
> if anything is broken, than the fact that sopen was included in an
> intransparent way.

Huh?  It's completely transparent, because it is so documented; if you
choose to ignore the documentation, then your blindness has nothing to
do with transparency.

> I did not include <io.h>,

You included unistd.h, where it is documented (yes, in the Open Source
world, the source is [part of] the documentation):

  /* unistd.h maps (roughly) to io.h
   * Other headers included by unistd.h may be selectively processed;
   * __UNISTD_H_SOURCED__ enables such selective processing.
   */
  #define _UNISTD_H
  #define __UNISTD_H_SOURCED__ 1

  #include <io.h>
  #include <process.h>
  #include <getopt.h>

> despite I have to deal with
> its function declarations.  In any sane system, I do not need to deal
> with things I do not use. This is currently not the case with mingw.
>
> For these reasons, I dare to make the bold statement that mingw has an
> issue with name space pollution. And if MinGW is not going to address
> this issue, it will bite others, too.

That may be so, but you are the sole voice making it an issue.  FWIW, I
originally joined the MinGW Project as a code porter (porting GNU code),
and was subsequently invited to join the administrative team on the
basis of my demonstrated abilities in this arena.  Do you think, in that
role, that I didn't have to deal with similar issue to yours?  Do you
think that I made a song and dance of them, claiming that MinGW was
broken, because some of these issues were a minor inconvenience to me?

> My patches might not be the
> perfect solution, but they demonstrate that addressing this issue is
> feasible.

Of course it's feasible.  Tor has already suggested NO_OLDNAMES as a
method for you to conceal the conflicting prototype; you rejected it
because you apparently want to have it both ways: have some OLDNAME APIs
exposed, while magically concealing just one which happens not to be
convenient for you!

Okay, you would like to see a more flexible mechanism for suppressing
declarations of Microsoft specific (extension) APIs, while continuing to
expose the declarations of those APIs which have sufficient commonality,
both syntactically and semantically, between MS-Windows and POSIX to be
considered as drop in replacements?  I could accept a patch which would
implement something along those lines, but none of those you've posted
here sets about addressing the issue in a rational manner; I will not
consider any of them as a viable candidate for inclusion in MinGW.

Now, Tor has further suggested a separation of io.h into two independent
parts: one for those APIs which would be relevant within the scope of
inclusion by unistd.h, (i.e. the [mostly] POSIX compatible APIs), and
those which are exclusively Microsoft's.  Well, such a separation is
*already* achievable *internally*, through inspection of the state of
__UNISTD_H_SOURCED__.  Thus, I *would* consider a patch which implements
an internal grouping of declarations within io.h, (and perhaps also
process.h; getopt.h should be okay, because it is already a MinGW POSIX
compatibility extension header), into the two respective categories.
However, such a patch will need to be much more comprehensive than a
mere kludge to address your one particular conflict du jour, (i.e. it
should make a best effort attempt to categorise *all* declarations
appropriately), and it must be submitted via the project patch tracker,
(*not* here), so that it may be subjected to the appropriate review and
follow-up process.

> I doubt that sopen from io.h is used by anyone because it is a relict
> from ancient times of single-task OS (like DOS, WIN95,98) for concurrent
> file access; nowadays, any sane multi-tasking OS provides this
> functionality within the standard functions (e.g. open).

Well, see Tor's response debunking that ludicrous suggestion!  Besides,
Win95 is still a supported MinGW target, and, while they may be becoming
few and far between, I believe we still have some users who would become
very upset if we were to drop support for it, without a better reason
than this.

> Whatsoever, if
> anyone wants to use io.h's sopen, it can still be included by an
> explicit #include <io.h>. But <io.h> as a whole should not be included
> through <unistd.h>.

Submit an appropriate patch, (as specified above), submit through the
appropriate channel, and we'll consider it.

>> Now, you may hack around with your own copy of MinGW to your hearts
>> content; if you want to modify it you are perfectly entitled to do so,
>
> I'm well aware of that ;-)
>
>> but, as Chuck said the other day, then your copy will no longer be
>> MinGW.  It's yours to do with as you please; if you break it, you get
>> to keep all the pieces for free.
>
> Strong words. The pieces can be quite useful to build something better.

Depends on what you consider to be better.  Submit a patch and we will
consider it on its merits; keep ranting here, and we'll just ignore you.

--
Regards,
Keith.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Keith Marshall
In reply to this post by Tor Lillqvist
On 23 November 2010 10:17, Tor Lillqvist <tml@...> wrote:
>> But <io.h> as a whole should not be included
>> through <unistd.h>.
>
> The only sane solution to this problem (if it is a problem), in my
> opinion, is to not have a <unistd.h> in MinGW at all. As this thread
> so painfully shows, it only misleads people into thinking that MinGW
> is attempting to offer a more Unix-like environment than it is. Having
> a <unistd.h> is a mistake.

That may be so, but it has been there for longer than I have been
associated with the project; to remove it now could be just too painful.
More palatable perhaps, would be an internal segregation of declarations
within io.h, as you suggested previously, with such segregation based on
the state of __UNISTD_H_SOURCED__.

--
Regards,
Keith.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Tor Lillqvist
In reply to this post by d3x0r
I wrote:

>> What does WINVER have to do with this at all? WINVER has a different
>> existing meaning, I don't see the point in reusing it for an unrelated
>> purpose.

To which J Decker replied, right after quoting my question above:

> Becaue it was a depricated function in 2005, so sopen should not exist
> for modern systems.

Hmm, I fail to see how that is a reply to my question how WINVER is
related to this.

Anyway, note that sopen() is deprecated in MSVC2005 documentation in
the same way that it says open() is deprecated.

For sopen(): "This POSIX function is deprecated beginning in Visual
C++ 2005. Use the ISO C++ conformant _sopen or security-enhanced
_sopen_s instead."

(Yes, indeed, the MSVC2005 documentation says that sopen() is a "POSIX
function"...)

For open(): "This POSIX function is deprecated beginning in Visual C++
2005. Use the ISO C++ conformant _open instead."

So if you are going to use MSVC2005 documentation as a base for
arguing that sopen() should not be declared in MinGW headers, then to
be consistent you also need to say that open() should not be there
either.

As such I think these "deprecations" are more based on politics and
marketing strategy than technical merits: Scaring people into using
totally Microsoft-specific APIs like _open() or _sopen_s() will of
course make it slightly harder to port their software to POSIX systems
like Linux.

--tml

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Michael T.
In reply to this post by Tor Lillqvist

> Not to mention a very basic C89 functions like strcpy() for instance
> that is in no way POSIX-related. It is also "deprecated"... yes, I am
> not joking, see
> http://msdn.microsoft.com/en-US/library/kk6xf663%28v=VS.80%29.aspx .
>

Well, Tor, do you think (not saying you have suggested this) that one should be scared to death to use such standard funcions (when they are deprecated)? Constantly analyzing whether something was or wasn't deprecated, or is or isn't included in a particular standard could take a lifetime. And I don't think anybody does that.
Don't you think there is something like a programmer's common sense or intuition to judge wether something would work or not? For instance, MinGW gcc is a C compiler. I sort of trust the creators and maintainers of MinGW, that they somehow took care of the basic C libraries, so that I am able to use all the non-POSIX specific functions on Windows. By the word  "basic" I don't even mean an exact set of libraries, it's a pseudo definition in my head, intuitive definition.
I'm not trying to say that being careful is wrong. But checking every function deeply against standards used would consume an enormous amount of time, and would be very uneffective. That's also why maintainers and community is present. If something unexpected (nontrivial; against common intuition) would have happened. The community of developers would be warned through a reliable channel - minGW website, this mailing list, etc.
This is a bit OT, but I'm interested in other opinions and ways of working.

myso

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Keith Marshall
In reply to this post by Tor Lillqvist
On 23 November 2010 11:38, Tor Lillqvist <tml@...> wrote:

> I wrote:
>
>>> What does WINVER have to do with this at all? WINVER has a different
>>> existing meaning, I don't see the point in reusing it for an unrelated
>>> purpose.
>
> To which J Decker replied, right after quoting my question above:
>
>> Becaue it was a depricated function in 2005, so sopen should not exist
>> for modern systems.
>
> Hmm, I fail to see how that is a reply to my question how WINVER is
> related to this.

As do I.

> Anyway, note that sopen() is deprecated in MSVC2005 documentation in
> the same way that it says open() is deprecated.
>
> For sopen(): "This POSIX function is deprecated beginning in Visual
> C++ 2005. Use the ISO C++ conformant _sopen or security-enhanced
> _sopen_s instead."
>
> (Yes, indeed, the MSVC2005 documentation says that sopen() is a "POSIX
> function"...)

That tickled me too; typical unresearched or ill informed bullshit from
Microsoft.  This would come as news to the POSIX Standards Committee; of
course sopen() isn't, and AFAIK never has been, any such thing.

> For open(): "This POSIX function is deprecated beginning in Visual C++
> 2005. Use the ISO C++ conformant _open instead."
>
> So if you are going to use MSVC2005 documentation as a base for
> arguing that sopen() should not be declared in MinGW headers, then to
> be consistent you also need to say that open() should not be there
> either.

...and, you can honour all such deprecations by -D_NO_OLDNAMES

> As such I think these "deprecations" are more based on politics and
> marketing strategy than technical merits: Scaring people into using
> totally Microsoft-specific APIs like _open() or _sopen_s() will of
> course make it slightly harder to port their software to POSIX systems
> like Linux.

That's my opinion too.

--
Regards,
Keith.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Tor Lillqvist
In reply to this post by Michael T.
> Well, Tor, do you think (not saying you have suggested this) that one should be scared to death to use such standard funcions

Of course not. Especially if one uses them in cross-platform code that
has been run under valgrind on Linux so that one can be fairly sure
that they are used correctly.

But obviously, Microsoft does have a point, in that careless use of
strcpy() can lead to hard-to-debug heap corruption errors. But
blatantly declaring standard C functions as "deprecated" is going a
bit too far.

(Anyway, if one is writing Windows-only code, well, why use C at all
in the first place, and not an inherently safer language like C#?
Which also can be quite portable to Linux and MacOSX, but I won't go
into that now.)

> Constantly analyzing whether something was or wasn't deprecated, or is or isn't included in a particular standard could take a lifetime.

Sure, but if you use Microsoft's compiler (and headers), it will warn
you when you use such "deprecated" functions. (Unless you instruct it
not to, by definiting some preprocessor macros.)

> Don't you think there is something like a programmer's common sense or intuition to judge wether something would work or not?

Sure. But on the other hand, common sense is hard to define.

--tml

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Keith Marshall
In reply to this post by Michael T.
On 23 November 2010 11:59, Michael T. <myso77@...> wrote:
>> Not to mention a very basic C89 functions like strcpy() for instance
>> that is in no way POSIX-related. It is also "deprecated"... yes, I am
>> not joking, see
>> http://msdn.microsoft.com/en-US/library/kk6xf663%28v=VS.80%29.aspx .
>
> Well, Tor, do you think (not saying you have suggested this) that one
> should be scared to death to use such standard funcions (when they are
> deprecated)?

That's not what Tor is saying, at all.

Like most of us who value code portability, I'm sure he does as I do:
recognising this banal Microsoft inspired deprecation for what it
undoubtedly is -- a marketing ploy to increase vendor lock-in potential
-- he ignores it, and just uses the more widely accepted (more portable)
function name anyway.  As long as _NO_OLDNAMES isn't defined, (and who
defines it, as a matter of course?), then portable code should mostly
compile and link just fine.

> Constantly analyzing whether something was or wasn't
> deprecated, or is or isn't included in a particular standard could
> take a lifetime. And I don't think anybody does that.

No, of course we don't.  That's not the issue here.  Most of us who
regularly write portable code recognise that some platforms, (and
MS-Windows is just one such notorious example), will occasionally bowl
us a googly, (cricketing term for a weirdly spinning curve ball), and we
take appropriate action to deal with it, when it arises.  What we don't
do, (and as the originator of this thread did), is turn to the
maintainers of the compiler suite and cry "foul".  Rather, we quietly
identify a method of working around the issue, within our own code, and
then, if appropriate, we apprise the maintainer of the affected package
of the problem, and offer our patch to address it.

--
Regards,
Keith.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Earnie Boyd
In reply to this post by Alois Schlögl
Alois Schlögl wrote:
>
> if anything is broken, than the fact that sopen was included in an
> intransparent way. I did not include <io.h>, despite I have to deal with
> its function declarations.  In any sane system, I do not need to deal
> with things I do not use. This is currently not the case with mingw.
>

This statement just shows that you have not been around systems
applications programming very long.  If you want protected namespace
then please use C++ and forget C.  Any programming instrument that
doesn't have strong namespace ability has the ability to add some
reserved word that you must now go a not use in your programs, legacy or
new.  Get over it and move on.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Alois Schlögl
In reply to this post by Keith Marshall
On 11/23/10 12:10, Keith Marshall wrote:

> On 23 November 2010 09:36, Alois Schlögl<[hidden email]>  wrote:
>    
>> On 11/22/10 17:31, Keith Marshall wrote:
>>      
>>> On Saturday 20 November 2010 23:24:52 Tor Lillqvist wrote:
>>>
>>>        
>>>> Maybe it would be a good idea if MinGW would split its<io.h>    into
>>>> two parts, and including it indirectly through<unistd.h>    would
>>>> bypass the Windows-specific APIs? Of course, such a change would
>>>> break some existing code. But it would help people in your situation.
>>>>          
>>> But, if it would break existing code, why should it be considered any
>>> better than the OP working around the issue appropriately in his own
>>> source -- i.e. by choosing a more appropriate (portable) name for his
>>> own function, so that he avoids the conflict with a publicly documented
>>> API on the porting platform he wishes to target?  This, after all, is
>>> precisely the sort of issue with which those who port software to any
>>> alternative host platform must be prepared to deal, and the preferred
>>> solution is invariably to modify the application source, not to hack
>>> (break) the tool chain to kludge around any single specific case.
>>>        
>> if anything is broken, than the fact that sopen was included in an
>> intransparent way.
>>      
> Huh?  It's completely transparent, because it is so documented; if you
> choose to ignore the documentation, then your blindness has nothing to
> do with transparency.
>
>    
>> I did not include<io.h>,
>>      
> You included unistd.h,

No, I've included zlib.h. The name space conflict was triggered by
#include <zlib.h>

zlib.h has
#include <zconf.h>

zconf.h has
#include <unistd.h>

unistd.h has
#include <io.h>

This is very deep nesting and needs pretty much investigating. More so
as the same thing works on other platforms.
I'm using Linux, and the same code is also used on OS X, and I guess its
not an issue with BSD. Its only mingw showing this kind of issue.

>> despite I have to deal with
>> its function declarations.  In any sane system, I do not need to deal
>> with things I do not use. This is currently not the case with mingw.
>>
>> For these reasons, I dare to make the bold statement that mingw has an
>> issue with name space pollution. And if MinGW is not going to address
>> this issue, it will bite others, too.
>>      
> That may be so, but you are the sole voice making it an issue.  FWIW, I
> originally joined the MinGW Project as a code porter (porting GNU code),
> and was subsequently invited to join the administrative team on the
> basis of my demonstrated abilities in this arena.  Do you think, in that
> role, that I didn't have to deal with similar issue to yours?  Do you
> think that I made a song and dance of them, claiming that MinGW was
> broken, because some of these issues were a minor inconvenience to me?
>
>    

Ok, could it be that this attitude led to the current situation - if the
namespace would be clean, we would not need this discussion.

I'm new to mingw, but I'm interested improving the user experience.
Based on my knowledge about mingw giving feedback is what I can do now.
(Even if it seems some of you are not interested in this). Of course and
I'm also willing to test better solutions.


    Alois



------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Andy Koppe
On 23 November 2010 13:30, Alois Schlögl wrote:

> No, I've included zlib.h. The name space conflict was triggered by
> #include <zlib.h>
>
> zlib.h has
> #include <zconf.h>
>
> zconf.h has
> #include <unistd.h>
>
> unistd.h has
> #include <io.h>
>
> This is very deep nesting and needs pretty much investigating. More so
> as the same thing works on other platforms.
> I'm using Linux, and the same code is also used on OS X, and I guess its
> not an issue with BSD. Its only mingw showing this kind of issue.

You still don't get it. MinGW gcc is a Windows compiler, and Windows
is a very different platform from Linux and other Unices. You do have
to expect and deal with issues like the one you encountered when
porting software from Linux to Windows (and vice versa).

MinGW does not aim to provide a Linux-compatible environment for
Windows; for that, you'll need to use Cygwin, with the Cygwin DLL
dependency that that entails.

Andy

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
12