MinGW-notify digest, Vol 1 #1375 - 1 msg

Send MinGW-notify mailing list submissions to
        mingw-notify-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
        mingw-notify-request-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx

You can reach the person managing the list at
        mingw-notify-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."


This list is used to send updates of submitted patches, bug reports and file 
releases.  You are discouraged from posting to this list.  If you wish to 
unsubscribe you can do so at 
https://lists.sourceforge.net/lists/listinfo/mingw-notify.

Today's Topics:

   1. [ mingw-Bugs-1424461 ] Avoidable namespace pollution in win32api 
(SourceForge.net)

--__--__--

Message: 1
To: noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx
From: "SourceForge.net" <noreply-pyega4qmqnRoyOMFzWx49A@xxxxxxxxxxxxxxxx>
Date: Wed, 24 May 2006 18:28:39 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1424461 ] Avoidable namespace pollution in 
win32api

Bugs item #1424461, was opened at 2006-02-05 23:26
Message generated for change (Comment added) made by dannysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1424461&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ron (ronl)
Assigned to: Danny Smith (dannysmith)
Summary: Avoidable namespace pollution in win32api

Initial Comment:
Hi,

Could we please uglify the #define'd "psuedo modifiers",
IN, OUT, and OPTIONAL (perhaps others) in win32api?

It is the latter which has burned the code I'm presently
porting, being the name of an enum, nested in a class,
in a named namespace.  It appears even the gcc source
dist that mingw releases uses OPTIONAL as an enum
value, so I'm not alone in thinking it is fair game in
my own
code.

I can't find anything that indicates this is for
compatibility with "native stupidity", and they are all
defined to nothing, so the name seems quite arbitrary and
safe to change to something a little less collision prone.

I can whip up a patch to fix this if we can agree on a
suitable name mangling (or you'll take whatever I pick;),
but its a pretty simple seach and replace in not too many
files -- so ping me if that will be helpful.

cheers,
Ron

----------------------------------------------------------------------

>Comment By: Danny Smith (dannysmith)
Date: 2006-05-25 13:28

Message:
Logged In: YES 
user_id=11494

> Is there still hope?

dum spiro, spero

No objections to my last ping so far, so I take it that 
this is OK 
Will wait 72 hrs then commit an updated version.

Danny

----------------------------------------------------------------------

Comment By: Ron (ronl)
Date: 2006-05-21 00:47

Message:
Logged In: YES 
user_id=78887

Hi.  I see 3.7 is out, and this was not applied to it.
Is there still hope?

cheers,
Ron


----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2006-03-07 09:00

Message:
Logged In: YES 
user_id=11494

Ping.  Are there still objections after Ron's suggestion to:

> If people are likely to (or do for certain) use them in
> their code and expect them to be defined, then we can
> retain full compatibility by default simply by adding:
>
>#ifndef W32_NO_PSUEDO_MODIFIERS  // or something 
appropriate
>  #define IN __W32_IN
>  #define OUT __W32_OUT
>  #define OPTIONAL __W32_OPTIONAL
> #endif
>
> to the previous patch, in some suitable place.

Danny

----------------------------------------------------------------------

Comment By: Ron (ronl)
Date: 2006-02-10 06:36

Message:
Logged In: YES 
user_id=78887

Ok.  I've just had a report that PWLib definitely uses 'IN',
so it seems at least some people have used them.

I would hope that we can still apply this patch, as an
enhancement, with the existing behaviour provided by
defining IN, OUT, and OPTIONAL, inside of a guard that
people may define to enable the enhancement (and use
code that uses these symbols without modification).

Recommending that people
#define IN IN
#define OUT OUT
#define OPTIONAL OPTIONAL
after including all w32api headers, seems like a poor second
option if we do not do something like this.

Thanks!
Ron


----------------------------------------------------------------------

Comment By: Ron (ronl)
Date: 2006-02-07 02:29

Message:
Logged In: YES 
user_id=78887

... also while making the patch, I noted the prior Changelog
entries:

Jun 22 2000  Christopher Faylor
  * rpcdce.h: Protect OPTIONAL definition since it may be
(legally) previously defined.

1998-12-02  Anders Norlander
  * include/rpcproxy.h: Removed IN, OUT and OPTIONAL since
they are meaningless.

The former may mean a number of things (may it legally be
defined to "any" value? -- obviously not if it is to work
as it does at present), but the latter made me wonder
whether I should not be using // as my replace string...

That seemed like not my decision to make though, so I stuck
to the plan.


----------------------------------------------------------------------

Comment By: Ron (ronl)
Date: 2006-02-07 02:16

Message:
Logged In: YES 
user_id=78887

Indeed, I noticed they were used in (some older) msdn
documentation while checking a signature that looked a
little odd when I was making the patch...

I would (have) be(en) personally inclined to interpret it as
a documentation convention in the msdn, and not at all
surprised to learn that the symbols themselves do not exist
anywhere in OEM headers -- though I don't know that as fact,
having never posessed, let alone seen them...   (I don't
know if we can confirm this cleanly one way or the other??)

But that is no matter if Earnie's concern is real.
If people are likely to (or do for certain) use them in
their code and expect them to be defined, then we can retain
full compatibility by default simply by adding:

#ifndef W32_NO_PSUEDO_MODIFIERS  // or something appropriate
  #define IN __W32_IN
  #define OUT __W32_OUT
  #define OPTIONAL __W32_OPTIONAL
#endif

to the previous patch, in some suitable place.
Then (otherwise) portable code, that did not originate with
msdn conventions, can be built on that platform without
changing symbols that under most conventions, should belong
to them (at least in their own namespace).

I'd probably prefer the default to be NOT to define them,
but this seems like a reasonable compromise that allows
both the msdn and other standards to co-exist side by side.

Does that satisfy your concern Earnie, or is there more that
I miss?

cheers,
Ron


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2006-02-07 01:36

Message:
Logged In: YES 
user_id=15438

Consider this an objection.  These psuedo modifiers are
documented in MSDN.  Should we change the what they are?

I don't consider this a bug.  It is more a request for
enhancement.

----------------------------------------------------------------------

Comment By: Ron (ronl)
Date: 2006-02-06 21:35

Message:
Logged In: YES 
user_id=78887

Ok.  The patch is too big to attach here.
(and the web interface (c)rudely dumped the comments I first
wrote too)

So you can grab it from:

http://people.debian.org/~ron/mingw/02-in_out_optional_ugly.patch

If __W32_ is no good it should be trivial to patch the
patch.  There is a little bit of whitespace normalisation
(mostly s/[\t]/  / to make the search and replace a bit
simpler, making the affected code look like the rest
around it) which touches some other lines in those files
-- but the diff -bd isn't significantly smaller.

Tested ok on all the code I threw at it here.  I'll upload
mingw-runtime_3.9-3 to Debian shortly which might help
anything I may have missed float to the top.

Thanks!
Ron


----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2006-02-06 09:51

Message:
Logged In: YES 
user_id=11494

Hello Ron

I would suggest __W32_IN, __W32_OUT, __W32_OPTIONAL,
but I'm not fussy about the colour of the bike shed.

If no one objects to that colour of ugliness in the next 24 
hours, I'll apply the patch to prefix __W32_.

Danny

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1424461&group_id=2435



--__--__--

_______________________________________________
MinGW-notify mailing list
MinGW-notify-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/mingw-notify


End of MinGW-notify Digest