Subject: RE: I: gcc ... -U_WIN32 ... may cause problems
From: [email-masked] (Michael Czapski)

11 Sep 1998 10:25:40 -0700
Message-ID: <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "[email-masked]'" <[email-masked]>

Hello People,
I am the silly b* who started this thread.  I am, sort of, sorry I did :-)
To brig it back to the original intent or kill it, rather than start another, I 
wish to remind what the original problem was:

IF one uses 'stat' call, AND one undefines _WIN32, AND one includes unistd.h 
THEN one may get into stack corruption issues, subtle 'bugs' and such like, 
totally unexpected and uncalled for, problems in a, otherwise perfectly fine, 
piece of C code.  I experienced this personally and traced it down to the 
__MS_types__ being defined when _WIN32 is defined and not beng defined 
otherwise.

Here is the extract from the original post:
---- begin extract ---
It turned out, after further investigation, that '__MS_types__' is defined in 
unistd.h and that this is what makes all the difference.
Now I code that as:
#if defined(__CYGWIN32__) && !defined(_WIN32)
#   define __MS_types__	/* this breaks stat function if not defined  */
#   define _MS_types_DEFINED	/* at the time unistd.h is included */
#endif
#include <unistd.h>
#if defined(__CYGWIN32__) && defined(_MS_types_DEFINED)
#   undef __MS_types__
#   undef _MS_types_DEFINED
#endif
This way I avoid defining _WIN32, can safely (?) undefine _WIN32 and code on 
the basis of 'if _WIN32 is not defined than it must be Unix or VMS' :-).
Since I found that workaround I stopped poking around to see what exactly 
breaks the 'stat'.  If anyone knows or finds out please let me know :-).

This message may, perhaps, save somebody a great deal of hassle in the future 
:-)
--- end extract ---

It would, in my opinion, be more beneficial to 'fix' the stat-related issue and 
allow people to use or not use _WIN32 as they see fit rather than discuss the 
merits of its being or not being there :-)

Sorry for unintentionally causing the prolonged discussion :-)

------------------
Cheers ...
Michael Czapski

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".