Talk:c/string/multibyte/wctomb
From cppreference.com
< Talk:c | string/multibyte
[edit] global
May I know the thinking behind using the word "global" in "internal global conversion state?" Newatthis (talk) 02:34, 5 September 2017 (PDT)
- It's explained in that same sentence, in parentheses. There are several functions in the C library that modify global variables, this is one of them. What is the thinking behind editing pages without discussing first? --Cubbi (talk) 12:49, 6 September 2017 (PDT)
- Many thanks for responding. Your feedback is not wasted on me. I use your feedback to adjust my participation in this wiki-project that is cppreference. I wish to respond to two topics. 1) ISO C11 uses the term "global" three times. Two of the three occurrences have nothing to do with "global variable." The third occurrence is actually "global variables," and refers to "the flags and modes in the floating-point environment" (F.9.1 Global transformations). Correct me if I am wrong, but I believe that those flags and modes have a behavior which is very different from the behavior of the variable/object holding the internal conversion state. Be that as it may, nowhere in ISO C11 is the term "global" used in conjuction with "internal conversion state." ISO C11 does not say that the internal conversion state "may be regarded as a global variable." So, the reader of this page might then turn to the larger programming world to seek the commonly used definition of "global." Doing that, the reader will find "a variable with global scope, meaning that it is visible (hence accessible) throughout the program, unless shadowed" and "a variable that can be used by all modules and functions in the program" and "the common practice is to keep global variables to a minimum" and "they can directly contribute to lowering the quality of the code." Global scope is not one of the four scopes of C. The internal conversion state is not accessible throughout a program since it is known only to the function that uses it. Also, I do not believe that you want to suggest that conversion functions are using a feature that lowers the quality of code. 2) On cppreference's FAQ, I saw "If you see something that is wrong, fix it" and "double check any changes with the appropriate standard. If you are unsure about anything, you can ask about it in the discussion pages." Well, I do believe that I am seeing something wrong; I did check the appropriate standard; and I am not unsure about this. Therefore, I did not feel the need to discuss my change before editing. Since you objected to my edit and questioned my behavior, I am discussing my edit now. I request that you reconsider your using "global" in this context. Newatthis (talk) 06:48, 7 September 2017 (PDT)
- I very much do want to suggest (or rather, note, since it's common knowledge) that using this function "lowers the quality of code". Just noting that it uses a global variable should be enough (if anything, I'd remove other unnecessary words like 'internal'), but it may be tempting to think calling the function would be safe for stateless encodings, so the note also mentions that it's thread-unsafe even then. And yes, all modules and functions in the program can modify that conversion state, it is similar to fenv modes, etc. --Cubbi (talk) 12:43, 7 September 2017 (PDT)