What purpose does __NO_ISOCEXT serve?

[Keith Marshall-3]

IMO, it is an aberration.  AFAICT, it is another mechanism, in addition
to __STRICT_ANSI__, for suppressing declarations which are not expected
to be specified in the ISO-C namespace.  In the mingwrt headers, I see
several instances where non-ISO-C declarations are conditionalized on
!__NO_ISOCEXT, but many more where !__STRICT_ANSI__ is used (abused?)
for the same purpose; there seems to be no rational explanation for the
particular choice made, in each instance.

I'd like to get rid of this aberration.  Unfortunately, there seems to
be an abundance of anecdotal evidence, on the internet, for it having
leaked into user space, (in spite of the double underscore prefix, which
*should* mark it as reserved for internal use by the runtime
implementation).  Thus, I propose folding it into a _mingw.h feature
test initialization, (_POSIX_C_SOURCE perhaps?), and replacing its use
elsewhere, with the appropriate *enabling* feature test.

Thoughts?  Objections?

--
Regards,
Keith.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie Boyd]

> -----Original Message-----
> From: Earnie
> Sent: Monday, December 22, 2014 4:03 PM
> To: 'MinGW Devlopers Discussion List'
> Subject: RE: [MinGW-dvlpr] What purpose does __NO_ISOCEXT serve?
>
> > -----Original Message-----
> > From: Keith Marshall
>
> >
> > IMO, it is an aberration.  AFAICT, it is another mechanism, in
> > addition to __STRICT_ANSI__, for suppressing declarations which are
> > not expected to be specified in the ISO-C namespace.  In the mingwrt
> > headers, I see several instances where non-ISO-C declarations are
> > conditionalized on
> !__NO_ISOCEXT,
> > but many more where !__STRICT_ANSI__ is used (abused?) for the same
> > purpose; there seems to be no rational explanation for the particular
> choice
> > made, in each instance.
> >
> > I'd like to get rid of this aberration.  Unfortunately, there seems to
> > be
> an
> > abundance of anecdotal evidence, on the internet, for it having leaked
> into user
> > space, (in spite of the double underscore prefix, which
> > *should* mark it as reserved for internal use by the runtime
> implementation).
> > Thus, I propose folding it into a _mingw.h feature test
> > initialization, (_POSIX_C_SOURCE perhaps?), and replacing its use
> > elsewhere, with the appropriate *enabling* feature test.
> >
> > Thoughts?  Objections?
>
> I agree that this is confusing and had thought about removing it.  Perhaps

give it
> a deprecated warning as well with a planned removal date in the warning.
>
> Earnie,
> Happy Holidays to all

I don't know that my response made it to the list.  See above.

Earnie


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr