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 |
> -----Original Message-----
give it
> 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 > 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 |
Free forum by Nabble | Edit this page |