Windows specific conditional code

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

Windows specific conditional code

Geert Janssens
Hi,

Another newbie question.

If I want to special case some codepath for Windows only what would be
the appropriate #ifdef incantation ?

I have seen several checks so far
#ifdef G_OS_WIN32
#ifdef MSWIN32
#ifdef _WIN32

The first one is used a lot in GnuCash, but I assume it's only available
when building with glib.

The others I have found in the guile source code.

Which one is the best one ?

Thanks,

Geert

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Eli Zaretskii
> From: Geert Janssens <[hidden email]>
> Date: Sat, 20 Sep 2014 14:18:52 +0200
>
> If I want to special case some codepath for Windows only what would be
> the appropriate #ifdef incantation ?
>
> I have seen several checks so far
> #ifdef G_OS_WIN32
> #ifdef MSWIN32
> #ifdef _WIN32
>
> The first one is used a lot in GnuCash, but I assume it's only available
> when building with glib.
>
> The others I have found in the guile source code.
>
> Which one is the best one ?

The last one, because every Windows-based compiler defines it.

However, if you need to condition code such that it is _not_ used on
Cygwin (which I believe is what you want in this case), you should do
this instead:

#if defined _WIN32 && !defined __CYGWIN__

Alternatively, if you want a condition that only triggers for MinGW,
use

#ifdef __MINGW32__

(Although this has "32" as substring, 64-bit MinGW builds will also be
caught.)

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Geert Janssens
On Saturday 20 September 2014 15:57:18 Eli Zaretskii wrote:

> > From: Geert Janssens <[hidden email]>
> > Date: Sat, 20 Sep 2014 14:18:52 +0200
> >
> > If I want to special case some codepath for Windows only what would
> > be the appropriate #ifdef incantation ?
> >
> > I have seen several checks so far
> > #ifdef G_OS_WIN32
> > #ifdef MSWIN32
> > #ifdef _WIN32
> >
> > The first one is used a lot in GnuCash, but I assume it's only
> > available when building with glib.
> >
> > The others I have found in the guile source code.
> >
> > Which one is the best one ?
>
> The last one, because every Windows-based compiler defines it.
>
> However, if you need to condition code such that it is _not_ used on
> Cygwin (which I believe is what you want in this case), you should do
> this instead:
>
> #if defined _WIN32 && !defined __CYGWIN__
>
Thanks for the informative answer.

Why would I want to exclude cygwin ? Because it uses glibc ?


> Alternatively, if you want a condition that only triggers for MinGW,
> use
>
> #ifdef __MINGW32__
>
> (Although this has "32" as substring, 64-bit MinGW builds will also be
> caught.)
>
That's good to know also. In case of strfmon, I suppose your first
suggestion is better. If someone would want to build gnucash with Visual
Studio, the lconv members would still be missing right ?

I doubt gnucash can currently be built in Visual Studio, but at some
point it was possible. And for sure I don't want *my* changes to turn
out to be a roadblock :)

Geert

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Eli Zaretskii
> From: Geert Janssens <[hidden email]>
> Date: Sat, 20 Sep 2014 15:07:20 +0200
>
> Why would I want to exclude cygwin ? Because it uses glibc ?

No, Cygwin doesn't use glibc.  (I told you: almost no system but
GNU/Linux does.)  But Cygwin attempts to be GNU/Linux-compatible, so
it is quite likely that they do have strfmon in their libc.  To be
sure, you should ask on the Cygwin mailing list, though.

> > Alternatively, if you want a condition that only triggers for MinGW,
> > use
> >
> > #ifdef __MINGW32__
> >
> > (Although this has "32" as substring, 64-bit MinGW builds will also be
> > caught.)
> >
> That's good to know also. In case of strfmon, I suppose your first
> suggestion is better. If someone would want to build gnucash with Visual
> Studio, the lconv members would still be missing right ?

That's true.  I just assumed that, since you asked about libmingwex,
that you didn't intend to support the Microsoft compiler.

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Geert Janssens
On Saturday 20 September 2014 16:20:06 Eli Zaretskii wrote:

> > From: Geert Janssens <[hidden email]>
> > Date: Sat, 20 Sep 2014 15:07:20 +0200
> >
> > Why would I want to exclude cygwin ? Because it uses glibc ?
>
> No, Cygwin doesn't use glibc.  (I told you: almost no system but
> GNU/Linux does.)  But Cygwin attempts to be GNU/Linux-compatible, so
> it is quite likely that they do have strfmon in their libc.  To be
> sure, you should ask on the Cygwin mailing list, though.
>
Ok.

> > > Alternatively, if you want a condition that only triggers for
> > > MinGW,
> > > use
> > >
> > > #ifdef __MINGW32__
> > >
> > > (Although this has "32" as substring, 64-bit MinGW builds will
> > > also be caught.)
> >
> > That's good to know also. In case of strfmon, I suppose your first
> > suggestion is better. If someone would want to build gnucash with
> > Visual Studio, the lconv members would still be missing right ?
>
> That's true.  I just assumed that, since you asked about libmingwex,
> that you didn't intend to support the Microsoft compiler.

Oh right. I didn't really ask about libmingwex. It was Keith that
pointed me in that direction. I do keep this in the back of my mind in
my current effort though so I can eventually propose a patch for
inclusion.

I try to work on strfmon one step at the time. The first one is to
include it directly into gnucash. That will already force me to fix it
enough so it can be used on windows. At this level I want to keep my
changes to strfmon generic, so that other platforms that don't have
strfmon by default either can still use the local copy in GnuCash
without being restricted to the locale offering imposed by Windows.

Once I get that working, I will check what is needed to propose it for
inclusion in mingw. At that point I suppose I can remove all the
conditional code completely as it will only be used inside a mingw
environment. Or is that too simplistic a view ?

Geert

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Eli Zaretskii
> From: Geert Janssens <[hidden email]>
> Cc: [hidden email]
> Date: Sat, 20 Sep 2014 15:34:22 +0200
>
> I try to work on strfmon one step at the time. The first one is to
> include it directly into gnucash. That will already force me to fix it
> enough so it can be used on windows. At this level I want to keep my
> changes to strfmon generic, so that other platforms that don't have
> strfmon by default either can still use the local copy in GnuCash
> without being restricted to the locale offering imposed by Windows.
>
> Once I get that working, I will check what is needed to propose it for
> inclusion in mingw. At that point I suppose I can remove all the
> conditional code completely as it will only be used inside a mingw
> environment. Or is that too simplistic a view ?

I'd rather suggest to make a configure-time test for strfmon
(including any of its features that you actually depend on), and if
the test discovers that these features are not supported, use the
replacement code.  This way, your code will work both for MinGW
versions that don't have strfmon and those which do, without the need
to test for MinGW versions.  Moreover, it will also work for other
platforms, because localeconv is an ANSI C function, so I'd expect it
to be available on all platforms you support.

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Geert Janssens
On Saturday 20 September 2014 19:01:12 Eli Zaretskii wrote:

> > From: Geert Janssens <[hidden email]>
> > Cc: [hidden email]
> > Date: Sat, 20 Sep 2014 15:34:22 +0200
> >
> > I try to work on strfmon one step at the time. The first one is to
> > include it directly into gnucash. That will already force me to fix
> > it enough so it can be used on windows. At this level I want to
> > keep my changes to strfmon generic, so that other platforms that
> > don't have strfmon by default either can still use the local copy
> > in GnuCash without being restricted to the locale offering imposed
> > by Windows.
> >
> > Once I get that working, I will check what is needed to propose it
> > for inclusion in mingw. At that point I suppose I can remove all
> > the conditional code completely as it will only be used inside a
> > mingw environment. Or is that too simplistic a view ?
>
> I'd rather suggest to make a configure-time test for strfmon
> (including any of its features that you actually depend on), and if
> the test discovers that these features are not supported, use the
> replacement code.  This way, your code will work both for MinGW
> versions that don't have strfmon and those which do, without the need
> to test for MinGW versions.  Moreover, it will also work for other
> platforms, because localeconv is an ANSI C function, so I'd expect it
> to be available on all platforms you support.

I guess I wasn't too clear because what you write is exactly what I'll
do in GnuCash. Add a replacement strfmon function that will only be used
if the platform doesn't support it. Otherwise use strfmon provided by
the platform.

Then I want to propose a strfmon function for inclusion in mingw. In
*this* function I would remove the conditionals, because it would only
be used on the "mingw platform".

So in the end gnucash will always have a strfmon function, either the
platform provided one (which could come from a future version of mingw)
or the internal, replacement one.

Does that make sense ?

I'm close to finishing the gnucash part by the way. It compiles but I
still have to thoroughly test it. So the next step would be libmingwex.

Where can I find the source of libmingwex to figure out how to make a
patch against it ?

Geert

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Eli Zaretskii
> From: Geert Janssens <[hidden email]>
> Cc: [hidden email]
> Date: Sat, 20 Sep 2014 18:15:20 +0200
>
> Then I want to propose a strfmon function for inclusion in mingw. In
> *this* function I would remove the conditionals, because it would only
> be used on the "mingw platform".

Ah, okay, it's my misunderstanding then.  Yes, in the version to be
included in libmingwex there's no need for any conditionals.

> Where can I find the source of libmingwex to figure out how to make a
> patch against it ?

I'll let Keith answer that, as I myself never did anything like that.

Thanks.

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Peter Rosin
In reply to this post by Eli Zaretskii
On 2014-09-20 14:57, Eli Zaretskii wrote:
> The last one, because every Windows-based compiler defines it.
>
> However, if you need to condition code such that it is _not_ used on
> Cygwin (which I believe is what you want in this case), you should do
> this instead:
>
> #if defined _WIN32 && !defined __CYGWIN__

Cygwin compilers do not define _WIN32. Maybe they did a very long
time ago, or maybe you are attempting to defeat broken code that does
the equivalent of

        #ifdef __CYGWIN__
        #define _WIN32
        #endif

But any code that abuses Cygwin like that is IMHO just that, broken.

        #ifdef _WIN32

should be enough.

Cheers,
Peter


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Keith Marshall
On 22/09/14 11:41, Peter Rosin wrote:

> On 2014-09-20 14:57, Eli Zaretskii wrote:
>> The last one, because every Windows-based compiler defines it.
>>
>> However, if you need to condition code such that it is _not_ used on
>> Cygwin (which I believe is what you want in this case), you should do
>> this instead:
>>
>> #if defined _WIN32 && !defined __CYGWIN__
>
> Cygwin compilers do not define _WIN32.

I don't use Cygwin, so this is not authoritative; however, Chuck Wilson
-- a Cygwin developer, who has also contributed extensively to MinGW --
has always been quick, in the past, to contradict any such assertion.

Essentially, Cygwin compilers do not *automatically* define _WIN32, but
there are certain circumstances of *cygwin* header inclusion which *do*
cause it to become defined.  I don't believe that Cygwin developers
consider this to be broken behaviour, but rather intentional, and
expected; thus, Eli's recommendation is appropriate.

--
Regards,
Keith.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Eli Zaretskii
> Date: Mon, 22 Sep 2014 13:58:24 +0100
> From: Keith Marshall <[hidden email]>
>
> Essentially, Cygwin compilers do not *automatically* define _WIN32, but
> there are certain circumstances of *cygwin* header inclusion which *do*
> cause it to become defined.  I don't believe that Cygwin developers
> consider this to be broken behaviour, but rather intentional, and
> expected; thus, Eli's recommendation is appropriate.

Thanks.

It's not that I'm so smart, I just read gnulib sources a lot, and they
are still full of the likes of

  #if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
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: Windows specific conditional code

Peter Rosin
In reply to this post by Keith Marshall
On 2014-09-22 14:58, Keith Marshall wrote:

> On 22/09/14 11:41, Peter Rosin wrote:
>> On 2014-09-20 14:57, Eli Zaretskii wrote:
>>> The last one, because every Windows-based compiler defines it.
>>>
>>> However, if you need to condition code such that it is _not_ used on
>>> Cygwin (which I believe is what you want in this case), you should do
>>> this instead:
>>>
>>> #if defined _WIN32 && !defined __CYGWIN__
>>
>> Cygwin compilers do not define _WIN32.
>
> I don't use Cygwin, so this is not authoritative; however, Chuck Wilson
> -- a Cygwin developer, who has also contributed extensively to MinGW --
> has always been quick, in the past, to contradict any such assertion.
>
> Essentially, Cygwin compilers do not *automatically* define _WIN32, but
> there are certain circumstances of *cygwin* header inclusion which *do*
> cause it to become defined.  I don't believe that Cygwin developers
> consider this to be broken behaviour, but rather intentional, and
> expected; thus, Eli's recommendation is appropriate.

Oh, I'm pretty sure that no "core" Cygwin package does this. On the
contrary, I think Cygwin is pretty careful to *not* define _WIN32.
Certainly, some fringe package in the distribution could do it, but
I do think the Cygwin developers would rather have packages that
didn't. Anyway, as a smoke test, I did this search on my Cygwin
/usr/include:

$ grep -r '#.*define[^d].*_WIN32' /usr/include/* | grep '[^A-Z0-9]_WIN32\([^_].*\)\?$'
/usr/include/libltdl/lt_system.h:# define __WINDOWS__ _WIN32
/usr/include/tcl.h:#        define _WIN32
/usr/include/tcl8.5/generic/tcl.h:#         define _WIN32

So, on my Cygwin install, only tcl does this thing which I consider
broken. Looking in /usr/include/tcl.h, I find this:

/*
 * The following definitions set up the proper options for Windows compilers.
 * We use this method because there is no autoconf equivalent.
 */

#ifndef __WIN32__
#   if defined(_WIN32) || defined(WIN32) || defined(__MINGW32__) || defined(__BORLANDC__) || (defined(__WATCOMC__) && defined(__WINDOWS_386__))
# define __WIN32__
# ifndef WIN32
#    define WIN32
# endif
# ifndef _WIN32
#    define _WIN32
# endif
#   endif
#endif

(It looks the same in /usr/include/tcl8.5/generic/tcl.h)

It seems that tcl.h defines _WIN32 for a bunch of Windows
compilers that probably already defines it, plus the
unfortunate case when WIN32 is defined. I think WIN32 is
defined when including just about anything from Win32, and
windows.h in particular.

So, including windows.h followed by tcl.h will get you in a mess
if you don't exclude __CYGWIN__ in your guard. I wonder how
relevant that case is? And there's also the question of how many
Cygwin dev packages that I have not installed [*] and grep-ed...
And I suppose some code might define _WIN32 all by itself.

Better safe than sorry I guess, but it is horrible. Sigh.

Cheers,
Peter

[*] An indication would be:
$ find /usr/include | wc
  19043   19043  871093


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
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