<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Some thoughts on namespace ...<div class=""><br class=""></div><div class=""><div class=""><span class="" style="font-family: "Helvetica Neue";">CFP has tried to add full support for IEC 60559 by following existing C style and with minimum invention of language features. </span></div><div class=""><span class="" style="font-family: "Helvetica Neue";"><br class=""></span></div><div class=""><span class=""><font face="Helvetica Neue" class="">IEC 60559 calls for a huge number of interfaces ~= operations X types. C doesn’t have a mechanism for managing namespaces for external linkage.</font></span></div><div class=""><span class=""><font face="Helvetica Neue" class=""><br class=""></font></span></div><div class=""><span class=""><font face="Helvetica Neue" class="">Would have been a better topic 8 years ago.</font></span></div></div><div class=""><span class=""><font face="Helvetica Neue" class=""><br class=""></font></span></div><div class=""><span class=""><div class="">Paper contains two kinds of proposals, with some overlap. Ones related to namespace and ones related to style. Some separation might be needed.</div><div class=""><br class=""></div><div class=""><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">1. </div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">Most of your proposed changes are intended to reduce the likelihood of conflict. They don’t reduce the number of identifiers from the current user namespace. So argument from hypothetical probabilities seems questionable. Could data bases of user code be searched for instances of new identifiers?</div></div><div class=""><br class=""></div><div class=""><div class="">HPUX had/has something like: entry points in libm had a normal primary name, _cospi, and a secondary name, cospi; math.h had #define cospi(x) _cospi(x), and the linker would use the secondary name only if a primary name were not found. User code produced primary names. Also, links sequenced standard libraries last in the search order, where possible. I believe all this managed to avoid most conflicts, though was not perfect. </div><div class=""><br class=""></div><div class="">HP added five types (extended, quad, _Decimal32, _Decimal64, and _Decimal128) each with a full set of macros and suffixed functions, without namespace complaints from users that I recall.</div><div class=""><br class=""></div><div class=""><div class=""><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">1.1 </div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">cr prefix misrepresented. See below.</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">1.1 </div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">Why are reserved identifiers better than new types?</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font style="font-family: "Helvetica Neue";" class="">1.2 </font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font style="font-family: "Helvetica Neue";" class="">Backing out or changing TS3 might be reasonable. TS3 goes beyond type </font><font face="Helvetica Neue" class="">extensions in order to support portable programming, by adding redundant types, could have double = _Float64 = _Float32x. </font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Is adding math functions with fN and dN suffixes really going to coopt many user names? If name reservation is needed, why not just reserve names with these suffixes rather than new prefixes?</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">(1) basically adding macro operators</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">type could be controlled with casts, e.g., #define sqrtf(x) sqrt((float)x)</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Implementations would have internal names for all the typed functions. Could typed math functions be treated as macro operators?</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Hard to do without separating math library into pre and post C2X without breaking old code.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">(2) How would this help with the external linkage issue?</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Does CFP have any objection to putting decimal into <decmath.h>? It would mean a lot of redundant specification or a lot of references. Or could make 7.12 for <math.h> and <decmath.h>.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Q1 - open or agree - Namespace aside, TS3 is complicated and has no full implementations.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Q2 - question not clear - how does C allow user to control external linkage?</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">It’s the TS not its integration that determines compatibility - integration is an editorial function.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Q3 - what interfaces specifically are being referred to?</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Is this be different from Q2.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Q4 - need more specifics. what would this mean for interchange and extended types?</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span style="font-family: "Helvetica Neue";" class="">2.</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;">Having two different naming styles for similar functions, in the same header, <font face="Helvetica Neue" class="">e.g. for the old exp2 family and the new exp10 family, would be an ongoing inefficiency and annoyance for users, who would have to memorize or look up which functions use which style. </font></div></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">A different scheme for these concerns could be something like a new <math_.h> header that provided all the suitable old and new math interfaces as they are now but with a reserved math_ prefix. Then <math.h> might continue as in C17. This would provide a simple consistent naming scheme for new code, and the general scheme would be extensible to other headers if needed.</font></div></div><div class=""><br class=""></div><div class="">3.1 </div><div class="">The proposal to use _t type names seems like a different issue. It offers nicer names but it increases rather than decreases the number of reserved names. Might users have widely adopted names with _t for their own types?</div><div class=""><br class=""></div><div class="">What is the practical advantage of avoiding keywords? Implementation would have to have their own internal keyword-equivalents anyway.</div><div class=""><br class=""></div><div class="">fltN_eval_t would be more expressive than floatN_t, which might be too similar to fltN_t.</div><div class=""><br class=""></div><div class="">3.2 </div><div class="">_WIDTH is not a math.h feature, nor a floating point one per se.</div><br class=""><div class="">Is there foreseeable further use of the _WiDTH suffix, not covered by the (U)?INT reservation?</div><div class=""><br class=""></div><div class="">3.4 - 3.7</div><div class=""><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">Why prefixes over suffixes? Current C style generally uses suffixes. Why not reserve the current suffixes fN, dN, fNx, dNx?</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">Type prefixes instead of suffixes would mean names sort by type instead of function family. This would make using the index and other lists more difficult. This is part of the reason I find the lists in the proposal difficult to grok.</div></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">3.8 and 1.1</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">There is no reserved sqrt with a cr prefix. I don’t think there are any conflicts.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">It’s important to reserve names for correctly rounded math functions, for use by early (including current) implementers.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class="">CFP would support a proposal to change the cr prefix to cr_.<br class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">3.9 </font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Just looking at numbers, reserving prefixes or suffixes removes more names from user namespace. </font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">An attempt to use prefixes to create namespaces for argument types.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">3.9.1</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">fe_ is used only for fe_dec_getround and fe_dec_setround, which correspond to fegetround and fesetround. This was a concession to easier reading, not intended to introduce a new prefix.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span style="font-family: "Helvetica Neue";" class="">3.9.3,4</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">cmplx_flt_acospi vs cacospif</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Is this a significant namespace issue, or mostly about style.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">3.10</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">d64muld128, and the other functions that round to narrower type, follow the convention of prefix for result type and suffix for parameter type, which helps with parsing the name.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Question 13 is just about the prefix for the result type, right? toflt_addl vs faddl?<br class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">3.11.1</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">See 3.1 above.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">What does “as if by typedef …” accomplish? If fltN_t is as if by typedef, then the corresponding complex types can’t be designated as </font><span class="" style="font-family: "Helvetica Neue";">fltN_t _Complex. Would need something like </span><font face="Helvetica Neue" class="">fltN_cmplx_t</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class="" style="font-family: "Helvetica Neue";"><br class=""></span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class="" style="font-family: "Helvetica Neue";">_DecimalN has been in use for quite a while, doing back to the decimal TR. </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class="" style="font-family: "Helvetica Neue";"><br class=""></span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class=""><font face="Helvetica Neue" class="">A style issue.</font></span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">3.11.2</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">FENV_ is only used after #pragma STDC, so it’s not a namespace issue. Except for _Pragma?</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Proposal would break consistency in pragma naming.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">3.11.3</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Introduces an inconsistency for a slight namespace benefit. Only fesetexcept, fetestexceptflag, fegetmode and fesetmode.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">3.11.4</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">The names with “from" fits better with the scheme of return type prefixes and parameter type suffixes.</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; font-family: "Helvetica Neue";">3.11.5 - 3.11.6</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;">The proposed renaming to toint_logb and toint_quantexp doesn’t tell the return type. </div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">(logb better not viewed as a log followed by a conversion.)</font></div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;">So would have ilogb and toint_logb.</div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;">This scheme wouldn’t extend to existing functions lrint and llrint and lround and llround.</div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;">3.11.7</div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;">The type-suffix style naming for INFINITY and NAN, and carried on with SNAN, came from the use of that style for the similar math.h macro HUGE_VAL</div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;">We could put INFINITY, NAN, and SNAN with prefixes in float.h and obsolesce the suffixed ones in math.h.</div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;">3.11.8</div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;">Changing CR_DECIMAL_DIG to FP_DECIMAL_DIG loses the indication of correct rounding, which is key to the meaning.</div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">CR_DECIMAL_DIG isn’t a significant namespace issue.</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class="">Some options regarding namespace:</font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><div class="">0. reduce user namespace, following TS</div><div class=""><br class="">1. reserve type-prefixes and rename, as Jens suggests<br class=""><br class="">2. reserve a math prefix and rename, e.g., math_sinpi, perhaps in new header <math_.h><br class=""><br class=""><div class="">3. add some form of namespaces, e.g., similar to C++’s</div><div class=""><br class=""></div><div class="">4. prefix new identifiers with two underscores, e.g., __sinpi</div><div class=""><br class=""></div>5. keep TS function names but reserve suffixes, maybe add “d” suffix for double<br class=""><br class="">6. make math functions generic only (Jens idea)<br class=""><br class="">7. remove Annex N from C2X and put it in a TS update<br class=""><br class=""></div><div class="">8. change Annex N to a proposal for adding IEC 60559 floating types only for added formats, hence e.g., no _Float32<br class=""><br class="">9. back out decimal extensions, as Jens has suggested</div><div class=""><br class=""></div><div class="">What has been C’s position on adding namespaces? Could it be an optional feature, required for library extensions like ours?</div><div class=""><br class=""></div></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><font face="Helvetica Neue" class=""><br class=""></font></div><div class="" style="font-family: "Helvetica Neue"; margin: 0px; font-stretch: normal; line-height: normal;"><br class=""></div></div></div></div></div><div class=""><font color="#ff2600" class=""><br class=""></font></div></div></span></div></body></html>