Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
FYI the attribute concept, along with "pure" and "const" sttribute should enter in next C1x
standard, but possibly with other name.
Posted Jun 11, 2008 11:44 UTC (Wed) by Yorick (subscriber, #19241)
Posted Jun 11, 2008 12:16 UTC (Wed) by cate (subscriber, #1359)
It is a working document (and a subsequent document document "const", giving better hints that
pure is allowed to read memory).
Anyway the version in standard should behave as gcc (or ev. as microsoft c compiler). They
really don't want (in next revision) to create alternate behaviors.
Posted Jun 11, 2008 16:51 UTC (Wed) by madscientist (subscriber, #16861)
I really hope you're right, but in previous versions of the standard there was no interest by
the standards committee in how GCC does things. Basically their attitude was "if GCC wants
their compiler considered, they'll send someone to the standards committee to represent it.
If not, too bad." (I'm greatly paraphrasing comments by committee members posted on
comp.std.c). This might be understandable if GCC was a proprietary compiler that you had to
pay for... but it isn't of course. At the time GCC's support was confusing and no company had
the time and money to support a member at committee meetings.
Hopefully things will be better this time.
Times are changing
Posted Jun 12, 2008 8:35 UTC (Thu) by khim (subscriber, #9252)
At the time GCC's support was confusing and no company had the time and money to support a member at committee meetings.
The biggest problem at the time was RMS's position: GCC was supposed to be GNU C Compiler - and all other frontends were second-class citizens. Including C++. State-of-the-art GCC (the venerable 18.104.22.168) had awful C++ support and few developers used it as C++-compiler-of-choice. Eventually EGCS split happened, C++ support was improved to the point that now GCC is one of the C++ compilers - but all this happened after standard was finished. Today WG pays very serious attention to GCC: if some feature is flat-out rejected by GCC team it'll need A LOT OF supporters to be even considered. Thankfully GCC too pays close attention to what WG is doing so it's not a problem.
To WG difference between free compiler and proprietary one is NOT important. Difference between obscure and popular one is. As GCC's C++ compiler moved from obscurity to the compiler-of-choice it importance to WG moved similarly...
Posted Jun 12, 2008 13:00 UTC (Thu) by madscientist (subscriber, #16861)
What difference would it make to the C99 WG, what RMS's position was on C vs. C++, or the state of C++ in GCC at the time? There's no question that GCC was, even then, one of the most widely used C compilers around. My reference to proprietary compilers was meant to say that WG members couldn't/shouldn't be expected to pay for proprietary compiler licenses so they could learn about them: it's quite reasonable to expect those companies to pony up some $$ to send someone to the WG. For free software, there's nothing stopping the existing members from examining the docs and even the implementations directly, and/or asking questions on the mailing list to get details. Engaging the community that way, rather than requiring WG attendance or else ignoring the compiler, would have worked better for all concerned.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds