User talk:Newatthis



non-standard C in examples=

It's great to see the C section of this wiki getting some attention, but please verify your examples for standard conformance. At the very least, if you're using GCC or Clang, pass the -pedantic-errors switch to the compiler.

example from what I saw in more than one of the recently-posted examples, using clang:

test.c:7:5: error: plain '_Complex' requires a type specifier; assuming
      '_Complex double' [-Werror]
    complex z = cabs(1.0 + 2.0*I);
/usr/include/complex.h:40:18: note: expanded from macro 'complex'
#define complex         _Complex

--Cubbi (talk) 06:26, 10 February 2014 (PST)

Thanks for your feedback. I am using GNU GCC version 4.8.1 ( to develop my examples. Then, I test using GCC 4.8 (C99) on the preview feature ( to be sure that there is no warning or error from the compiler. Is this process sufficient to meet standard conformance? I really am new-at-this. I welcome your guidance. Newatthis (talk) 11:50, 10 February 2014 (PST)

no, GCC is not standards-compliant by default. It needs the --pedantic switch to report standard violations as warnings or --pedantic-errors to make them fatal. You could use and enter that switch at the compiler command line. --Cubbi (talk)
I was able to get a clean compile at coliru. I found -pedantic already entered on the command line. I made other changes with my limited knowledge of command-line arguments. In the end, I used this command:
    gcc -lm -O2 -Wall -pedantic -pthread main.cpp && ./a.out

I am about to move my source to cppreference to see whether it passes muster. Newatthis (talk) 12:49, 10 February 2014 (PST)

My example about csin() worked with a warning from Clang 3.4 (C99) but failed with GCC 4.8 (C99). The failure looked familiar, like the command line lacked "-lm". I continue to learn

how cppreference works. Newatthis (talk) 13:01, 10 February 2014 (PST)

language pages

When creating c/language/struct, you incorrectly copied (casting for unions) instead of using (casting for structs) and missed (flexible array member). Please be more careful with the language spec. --Cubbi (talk) 07:43, 2 March 2014 (PST)

Many thanks. I continue to learn from your critique. I am still climbing the language-spec ladder. Next, I shall learn what is.Newatthis (talk) 07:44, 3 March 2014 (PST) is a paragraph from the C programming language ISO standard (from its current, 2011, revision in this case). This site's FAQ as well as the C language history page have links to the downloadable PDF. --Cubbi (talk) 18:31, 5 March 2014 (PST)
Many thanks. I see paragraphs 15,16,18 and understand my error. I also see the syntax at the bottom of page 112. When I started working on the page for "struct", I found "struct name {} instance ;" The word "name" has carried through the history of edits. The syntax on p.112 uses "identifier". For the purposes and goals of cppreference, would "identifier" be more appropriate? Newatthis (talk) 06:11, 6 March 2014 (PST)

Please keep the examples concise

An example you posted is far too large. Please remember to keep the examples concise - this wiki is a language/library reference, not a tutorial or a book. The book project is here. --Cubbi (talk) 14:19, 12 March 2014 (PDT)


I noticed that you're using the floating-point environment in your examples. Please keep in mind that the way you're using it invokes undefined behavior under 7.6.1 if the default state of the FENV_ACCESS pragama is off (implementation-defined but generally true since enabling it by default removes a lot of optimizations). To quote 7.6.1, "If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma ‘‘off’’, the behavior is undefined. The default state (‘‘on’’ or ‘‘off’’) for the pragma is implementation-defined."

I've updated c/numeric/math/nextafter to use it correctly (and less excessively: examples are not meant to replace the reference documentation) and will update others when time allows. --Cubbi (talk) 09:42, 1 April 2014 (PDT)

Many thanks. You give me an opportunity to ask raise a couple of questions. First, your replacement example (as do many of my examples) yield undefined references followed by a ld error when compiling with "GCC 4.8 (C99)". Generally, compiling the same example with the alternate "clang 3.4 (C99)" works. Am I misusing's compiling facilities here? Secondly, regarding FENV_ACCESS, both compilers state that they are ignoring the "#pragma STDC FENV_ACCESS ON". clang even states that the pragma is not supported. This leaves me confused. With the compiler ignoring the pragma, how can we even think about using fenv.h? Newatthis (talk) 05:35, 2 April 2014 (PDT)
This wiki is a programming language reference, not a compiler reference. Some language features are not implemented by some compilers, or are implemented incorrectly, and it's not a reason to avoid them in the usage examples (actually my personal opinion is that such language features should definitely appear in the examples, to raise awareness). The lack of support for the STDC pragmas is a known bug in both compilers available at coliru: gcc #20785 clang #8100. To contrast, Oracle and IBM C compilers which I use at work, support it, as do some others. As for the ld error, we simply need to add -lm to GCC's compile options. --Cubbi (talk) 07:04, 2 April 2014 (PDT)
Many thanks for your explanation. I'll return to the examples with fenv.h and insert the pragma. Also, I'll reorient my focus to "programming language reference" from "compiler reference." I was using the two compilers provided to guide my examples. "To raise awareness" has been my personal opinion about the examples throughout my effort. Finally, perhaps will add "-lm" to its GCC compiler button so that I do not have to move to the clang compiler button to test my math.h examples. I always appreciate your feedback.Newatthis (talk) 07:24, 2 April 2014 (PDT)
I've added a -lm argument to the list of default arguments, but it doesn't seem to help for e.g. GCC on c/numeric/math/nextafter. If we figure out a good set of arguments that allows these examples to compile I'll be happy to make them the default. --Nate (talk) 07:57, 2 April 2014 (PDT)
-Wno-newline-eof should help clang and for gcc-4.8, -lm needs to be after main.cpp --Cubbi (talk) 08:28, 2 April 2014 (PDT)
Thanks, Cubbi. I've updated the arguments. --Nate (talk) 17:31, 3 April 2014 (PDT)
Thanks, Cubbi and Nate. Developing examples for math.h is now more convenient. On the other hand, not having GCC available for testing examples taught me that GCC and clang can behave differently with f-p exceptions. Newatthis (talk) 06:14, 4 April 2014 (PDT)

Please use descriptive names to all these new see-also links.

The links such as "types" or "atomic" are not meaningful, and even misleading, as they do not lead to a page about types, or a page about the type named "atomic" (they lead to the type support library page and the atomic operations library page, respectively. Please provide descriptive names. Assuming they are appropriate at all. --Cubbi (talk) 11:53, 4 June 2014 (PDT)

Thanks. I am studying your suggestion. Newatthis (talk) 12:17, 4 June 2014 (PDT)

the shape of c/language

I am concerned about a few things regarding your recent contributions to c/language:

  • pasting paragraphs of the ISO standard as-is does not make a helpful reference.
  • The new pages are too granular. Also, page names do not describe the contents: c/language/boolean_type does not specify _Bool, bool, true, or false, it is a two-line detail from the specification of implicit and explicit conversions in C (6.3).
  • examples are of questionable utility and the most recent one at c/language/real_and_complex is not even C (what are __real__ and __imag__?)

--Cubbi (talk) 07:42, 16 October 2014 (PDT)

Thanks, I am studying your comments. Newatthis (talk) 07:58, 16 October 2014 (PDT)
I replaced the GCC extension __real__ and __imag__ in the examples. Neither -pedantic nor -pedantic-errors exposed this extension. I am studying your other comments. Newatthis (talk) 09:07, 16 October 2014 (PDT)

ISO references on navigational pages

I am curious about the reasoning behind placing references to the ISO C standard on nagivation pages, such as c/string/byte, c/chrono, etc. I undid the introduction of ISO references to [c/string], which was obviously meaningless, but only very few things on other such pages are referenceable. For example, c/string/wide provides navigation to the reference pages on various wide string functions and also provides references for four typedefs (wchar_t, wint_t, wctrans_t, wctype_t) and three macros (WEOF, WCHAR_MIN, and WCHAR_MAX, although the last two belong in c/types/limits). I would imagine only those entities whose definitions are actually given on any particular wiki page can be meaningfully linked to an ISO standard chapter and clause. Links to other pages and their grouping aren't part of any standard, they are just layout choices of the wiki. --Cubbi (talk) 12:45, 8 April 2015 (PDT)

Since I was not a participant in the committee meetings that founded cppreference, I find myself second guessing the nature of what is desired. My first lesson: cppreference is not a tutorial. Typically, I look at what others contributed and try to contribute similarly. When I saw an expression of interest for references to the ISO C standard, there was not much to see. So, I looked at each page, including the navigation pages, to see what parts of the standard the material of each page covered. Just as the navigation pages offer a high-level view of the groupings chosen for this wiki, I thought that the "References" sections should reflect that high-level view of the chosen groupings. To me, a navigation page tells me to see the standard through the lens of the grouping; the references then tell me what to read as a coherent group. This seems better than trying to cobble together the related sections of the standard through individual function pages and their related clauses in the standard. Newatthis (talk) 11:32, 13 April 2015 (PDT)

non-functional examples

When publishing code, please make sure it compiles. The example for memmove_s, to take the latest one, added in [1] produces:

test.c: In function ‘main’:
test.c:17:9: error: redefinition of ‘r’
     int r = memmove_s(dst,5,src,10);            //  count is greater than destsz  
test.c:15:9: note: previous definition of ‘r’ was here
     int r = memmove_s(dst,sizeof dst,src,5);

and then changing line 15 to assignment instead of declaration earns a runtime error from the default constraint violation handler:

$ ./test
dst = "aaaaayxyxy", r = 0
abort_handler_s was called in response to a runtime-constraint violation.
The runtime-constraint violation was caused by the following expression in memmove_s:
n > s1max (in string_s.c:257)
Note to end users: This program was terminated as a result
of a bug present in the software. Please reach out to your
software's vendor to get more help.

to process constraint violations the way the example intended, the handler has to be reset to ignore. --Cubbi (talk) 10:04, 29 August 2015 (PDT)

Many thanks for your recent fixes to my attempts at writing _s examples. I studied each fix. I became confused about ignore_handler_s when I saw that you had deleted the setting of ignore_handler_s from the strncpy_s example on 23 August with the reason "unused code (and missing header)." I thought your fix should have been "#include <stdlib.h>". I see that on 29 August you inserted both the setting and the #include. So, I remain a little confused. Finally, should the memcpy_s example also set ignore_handler_s? Newatthis (talk) 04:32, 30 August 2015 (PDT)
see output quoted above, when you don't ignore handler you get an abort. So if you plan to demonstrate the return value or the zeroed-out array due to constraint violation, handler has to be ignored. Normal usage is to keep it as-is, not ignored. --Cubbi (talk) 06:23, 30 August 2015 (PDT)
Thanks. Your explanation is helpful. Another source of my confusion, also involving the original version of the example of strncpy(), was the line "int r2 = strncpy_s(dst2, 5, src2, 7); // copy would overflow the destination array". I thought that the impending overflow would have aborted the program leaving "int r3 = strncpy_s(dst3, 5, src2, 4); // writes zero to r3 and the 5 characters" unexecuted unless ignore_handler_s was set. As it is now, the example makes sense to me. Newatthis (talk) 06:56, 30 August 2015 (PDT)