| |||||||||||||
Std CStd CPosted Jun 11, 2008 11:44 UTC (Wed) by Yorick (subscriber, #19241)In reply to: Std C by cate Parent article: Implications of pure and constant functions That document is not quite consistent. It defines the attribute stdc_pure to indicate that a function "has no side effects and depends only on the values of the arguments passed". It then gives strlen as an example of such a pure function, contradicting the definition. It is unclear whether stdc_pure would correspond to GCC's const or pure attributes.
(Log in to post comments)
Std C Posted Jun 11, 2008 12:16 UTC (Wed) by cate (subscriber, #1359) [Link] 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.
Std C Posted Jun 11, 2008 16:51 UTC (Wed) by madscientist (subscriber, #16861) [Link] 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) [Link] 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 2.7.2.3) 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...
Times are changing Posted Jun 12, 2008 13:00 UTC (Thu) by madscientist (subscriber, #16861) [Link] Since we're talking about the C standard here, not the C++ standard, I'm not sure I understand your concern about the capabilities of C++ in GCC back "in the day". Although, you are definitely correct in your assessments, IMO.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.
|
|||||||||||||