Random: re your recent change, see <1139723148.805640.125020@g14g2000cwa.googlegroups.com> for a more robust approach. --Netocrat 22:42, 21 March 2006 (UTC)

Normally, yeah, but for this particular purpose we're the implementation. How do we decide whether to implement SIZE_MAX? if we define it unconditionally, we can't rely on it to decide whether the restrict keyword will work.

C89 compilers are free to define __cplusplus, too, that doesn't mean sane standard libraries have to deal with that possibility. --Random832 04:18, 22 March 2006 (UTC)

My idea is that as far as possible each block of implementation code be as portable and decoupled as possible, so that it could be "slotted in" to any other standard library with minimal change. So yes, we're the implementation, but the most portable and decoupled approach is to rely on SIZE_MAX's definition rather than __STDC_VERSION__ >= 199901l and to limit the reliance on __STDC_VERSION__ to the single point where we decide whether to define SIZE_MAX. --Netocrat 04:33, 22 March 2006 (UTC)

Why not just use a _RESTRICT macro, and have the check of __STDC_VERSION__ where that is defined? --Random832 04:39, 22 March 2006 (UTC)

One can certainly go to any lengths trying to outperform the standard comitees __STDC_VERSION__, but if we insist on making our own checks for C89 and not C90 conformance, we should better decide to set __STDC_VERSION__ appropriately if not already set. Let's just avoid creating another ugly macro. BTW: Don't we define SIZE_MAX ourselves in our own limits.h? Still, I personally don't feel we should bother with that. --Jannis 14:06, 22 March 2006 (UTC)

I think we should have a sample implementation of a non-portable header which is #include'd throughout the rest of our implementation. This header should assume that __STDC_VERSION__ is set appropriately, and define things like the _RESTRICT macro appropriately. Since the header is clearly marked as non-portable, we are covered for implementations where it is not set appropriately because the file requires tailoring anyway.

As to limits.h mentioned by Janis, that is one standard header that is fundamentally non-portable, so I think we just provide a sample implementation with everything set to the minimum limits commented appropriately. --Flash Gordon 14:17, 22 March 2006 (UTC)

Jannis: good call on the SIZE_MAX hack. Firstly, the post I referenced got it wrong - it's defined in stdint.h, not limits.h. Secondly, actually testing it on real-world compilers (gcc and icc) revealed that it's less reliable than __STDC_VERSION__ - gcc and icc define SIZE_MAX regardless of which version of the Standard they're asked to comply with. Also, you were right that there's a problem if __STDC_VERSION__ is not defined - it's a preprocessor error. I agree that it's good to avoid "another ugly macro", but the alternative is even uglier. The approach you suggest of defining __STDC_VERSION__ at this point if it's undefined assumes that we have control over the entire implementation and that it's OK mess with __STDC_VERSION__, which (in a pathological case) may not be true, but in any case it seems neater to use _NC_RESTRICT.

Flash: since the sample implementations are already listed on Non-Portable Standard Implementation Components (if used multiple times) or the page they occur on (if used once), that header would be redundant. It might be worth mentioning somewhere that the creation of that header is a good way to make those implementations available though. --Netocrat 02:03, 23 March 2006 (UTC)