Talk:C standard library/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2

Pages for each function and WP:NOTMANUAL

Hello,

I've noticed that there are quite a lot of new pages (like memccpy, mempcpy, strdup, etc.) for functions in the C standard library and its non-standard extensions. I feel that they serve no purpose, since all the material there falls into either of the following categories: a rehash of the standard or some online reference; a collection of tutorial-like tips or examples. Also, WP:NOTMANUAL explicitly forbids material like that. Thus I think these articles should be deleted. Since there was a lot of disputes regarding the deletion of other similar pages, we could take this opportunity to decide the fate of them too.

In my opinion a better way to document all these functions would be to have only a very concise definition in a page describing several functions (such as string.h) with a link to an actual reference, such as man pages, cplusplus.com, cppreference.com, wikibooks (for tutorials), etc., as is done here [wctype.h] or here [C++ vector] for example. Even the larger, more established pages (such as strcpy) could be reduced to such footprint, since most of their content is either not notable, fails WP:NOTMANUAL (especially in the case of printf), or would be reasonably represented in the linked reference webpage.

A different problem is with completely established pages, with a lot of WP:RS, such as malloc or printf: they mostly discuss a broader subject, not the function itself. In the case of malloc, different memory allocation strategies are discussed, not the malloc itself. This could be solved by repurposing the article and letting an external reference to do its work. However, this is not the core issue, so we can leave this for a separate future discussion.

Since this is quite controversial subject, that affect a lot of pages, we need to establish consensus over whether we need a change, and what we want to change. I think a usual poll would be a good idea. Since there are a lot of options, I've divided the poll into several separate questions.

Do we want to delete/redirect the pages?
  • 1) Do nothing. Leave everything as it is. It means that eventually each function in the C standard library has its own page. Unfortunately, WP:NOTMANUAL doesn't allow this. This option is doesn't solve anything.
  • 2) Delete/redirect new. Not fair because newer (not yet established) pages are discriminated. Examples of pages affected memccpy, mempcpy, strdup, etc.
  • 3) Delete/redirect all with exceptions. Do not delete/redirect the established pages such as malloc. Examples of pages affected: all of (2), plus strcpy, ect.
  • 4) Delete/redirect all. Delete/redirect all pages that would be deleted by (3). Repurpose existing pages to the actual subject, such as malloc -> memory allocation strategies. Affected pages: all of (3), plus malloc, fprintf, etc.; essentially any page describing a single C function.
  • ... (add your own option)
Do we need links to an external reference such as here [wctype.h] or here [vector]?
  • 1) Do not link to an external reference
  • 2) Link to an external reference
External reference website we will use (if we decided we need one)
  • 1) Depends on the situation. Cons: no consistency across pages.
  • 2) man pages, POSIX specifications, e.g. prinf on opengroup. Pros: extensive, complete, covers C99. Cons: covers POSIX, not C, so quite confusing as a lot of additional functions are present.
  • 3) MSDN reference, e.g. printf on MSDN. Pros: extensive, complete, covers C99. Cons: covers Microsoft's implementation of the C standard library, so quite confusing as a lot of additional functions are present.
  • 4) cplusplus.com, e.g. printf on cplusplus.com. Pros: extensive, complete. Cons: does not cover C99.
  • 5) cppreference.com, e.g. printf on cppreference.com. Pros: a public wiki, uses the same content engine and license as the Wikipedia - extensibility, familiarity to wikipedians. Covers C99. Extensive. Cons: several functions missing. Looks into the functionality from the C++ point of view, though as per their FAQ, a separate reference for C could be added if there is interest.
  • ... (add your own option)

1exec1 (talk) 09:00, 4 October 2011 (UTC)

I’m against actual deletion and prefer redirection. Deletion would make searching harder, and might encourage the same articles to be re-created with alternative names (strtok deleted, yet strtok_r later created). Redirection means you’re still allowed to use the name to link to a relevant article, and this might reduce the need for external linking. Otherwise I have no strong opinions on external links, although I am under the impression that there are subtle differences between some C functions and their C++ equivalents.Vadmium (talk, contribs) 11:13, 4 October 2011 (UTC).
I agree, actually the redirects were what I actually meant (it is still a delete content-wise though). I added a notice regarding that.1exec1 (talk) 11:28, 4 October 2011 (UTC)
I do agree that all these man-page-like articles need fixing up, and I actually started collecting a potential list of them earlier today at User:Vadmium/Man pages. The problem is not limited to functions, for example I’m not sure if stdlib.h and stddef.h are good places to pull together discussion of the things defined by those headers. Vadmium (talk, contribs) 11:13, 4 October 2011 (UTC).
I agree with redirecting the pages to their respective header pages, with some exceptions. malloc is essentially an article covering dynamic memory allocation in C, especially since calloc/realloc/free are all included there. printf should be moved to Format string (which is currently a redirect to there). mmap (POSIX) could be merged into Memory-mapped file. The pages on string functions (strcpy, strcmp, strcat, strlen) could be merged into the relatively short C string article - lots of the information on security implications and caveats is just duplicated on each page.
I think string.h could also be merged into C string. I know it would break the nice "article for every header file" thing, but the C standard library template could just be included there with string.h as a redirect. -- strcat (talk) 14:11, 4 October 2011 (UTC)
In my opinion, a page for each header is in itself not a very good idea, because in C a lot of functions performing similar functionality are dispersed across several headers (e.g. abs in stdlib.h, fabs in math.h). A better way would be to avoid grouping by header completely and use grouping by functionality instead.1exec1 (talk) 15:09, 4 October 2011 (UTC)

Status

Status of all pages involved in this reorganization can be tracked at User:Vadmium/Man pages

Poll

  • Redirect all. Link; use cppreference.com as the external reference. P.S. I use that site regularly so there's slight conflict of interest, shouldn't be a problem though.1exec1 (talk) 09:03, 4 October 2011 (UTC)
  • Redirect; write about groups of functions, header files, etc in articles like C file input/output. Vadmium (talk, contribs) 11:13, 4 October 2011 (UTC).
  • Redirect in almost all cases (ie there should be a redirect page with the name of each function, to avoid people recreating them). However a few articles with significant historical or controversy information must be preserved as-is. In particular the strlcpy article, as this is a common term found when researching controversy about the glibc library. A few others contain large amounts of information, such as printf, but as noted this information is often more of a cs subject and should be moved there.Spitzak (talk) 19:48, 4 October 2011 (UTC)
  • Wait and Transwiki all to WikiBooks, creating an appendix to b:C Programming. We should probably wait until November when Wikipedia:India Education Program/Courses/Fall 2011/Data Structures and Algorithms has finished (these people have been fairly uncommunicative so far and will probably stubornly recreate any article that has been deleted or redirected.) I'll request import> rights at WikiBooks and can temporarily undelete a few of the articles that have already been deleted here. —Ruud 13:24, 5 October 2011 (UTC)
I like this idea. But maybe we can do the import earlier, while there's strong momentum? I think it should be possible to negotiate with the curators of that course to continue their work in Wikibooks. It seems pointless to suspend so much cleanup work for a month, especially since most of the pages in question will end up in Wikibooks in any case. 1exec1 (talk) 14:00, 5 October 2011 (UTC)
I've imported mbrlen, which was recreated again, to Wikibooks. I've left a soft redirect behind. Is this an acceptable solution? —Ruud 16:28, 5 October 2011 (UTC)
Generally I think it would be better to redirect to some wikipedia page that mentions the particular function. I imagine that after the cleanup all functions will have entries in summary lists similar to that in wctype.h. Currently I don't know a summary page for mbrlen though. Unrelatedly, what do you think about my above proposal to negotiate with the curators of that India Education course?1exec1 (talk) 17:05, 5 October 2011 (UTC)
It could be redirected to <wchar.h> and we could in turn link to Wikibooks from that page. The question is if we want to keep the pages for the header files as well. I'd argue we'd only need this article on the C standard library and keep most of the detailed stuff in the Wikibook.
I've tried contacting a the ambassadors of the program last week but they simply ignored the request to join the discussion at WikiProject Computing. I'll leave a notice on each students talk page if I move their article to Wikibooks. Maybe they'll get the point eventually? —Ruud 17:29, 5 October 2011 (UTC)
Completely removing the material in these pages for header files would be something too much IMO. A better solution, which was suggested above, would be to merge the content to other pages, while removing non notable and tutorial-like material. However, you should import the header pages to wikibooks also, because these pages will become redirects after the cleanup.
A notice in the user pages would be enough IMO. In any case, if even the ambassadors don't care, why should we? Wikipedia is not for homeworks.1exec1 (talk) 17:55, 5 October 2011 (UTC)
I don't think merging e.g. alloc.h with Memory management would be a good idea. That article covers (or at least should cover) memory management at a slightly more abstract level. If we start including C specific stuff their, we would also have to include material for dozens of other languages. I'd have a slight preference for merging the headers here, but keeping separate articles for the header files would probably be okay as well. Let's see what other people have to say on this. I'll import the articles on the header files to Wikibooks as well. —Ruud 18:13, 5 October 2011 (UTC)
Something like C memory management or Memory management in C would be more sensible, I agree. Better yet, we could have C and C++ memory management and to merge several other articles there.1exec1 (talk) 18:46, 5 October 2011 (UTC)
In any way, I think we should only decide general approach in this discussion. Article specific stuff should go into their talk pages.1exec1 (talk) 18:48, 5 October 2011 (UTC)
It would be a fair idea to merge the content in alloc.h with a page like C memory management , but if a page like this is created, it raises the question of creating similar pages for all the programming languages in the world. A compilation of similar pages would also act like a manual, listing out memory management in various languages. Srinathkr3 (talk) 03:11, 6 October 2011 (UTC)
I disagree that we can call such pages manuals. The function list would be a minor detail, compacted as much as possible. The main focus would go into explaining different memory allocation strategies (such as stack or heap) and similar things. This is not a manual. If it was, then we could easily count several thousands of established pages (e.g. C++11), that would need deletion. Here we are against small pages containing material, that would be interesting to a programmer who was about to use some function.1exec1 (talk) 11:35, 7 October 2011 (UTC)
If you’re looking for a C memory management article, check out the current scope of malloc; it even has a section called malloc#Dynamic memory allocation in C. Might be best to start by renaming that page. Vadmium (talk, contribs) 06:00, 6 October 2011 (UTC).
  • Redirect all. Either we have to document ALL the library (which is way out of score of wikipedia) or delete the functions. After all, one that wants to learn about strcpy or anything else will not usually expect Wikipedia to contain details. Michael (talk) 20:14, 6 October 2011 (UTC)
  • How can you call this concensus and where is the conclusion then? - Discussing a lot of articles here? I think its rather strange to use this talk page as an argument. Why not include the wikiproject discussion page? Christian75 (talk) 18:33, 23 October 2011 (UTC)
As I've already said in some edit summary, a lot more editors are not watching Wikiproject pages. By the way, there already has been a discussion and there's a link to this discussion there, so this is not an issue. Also, I've placed links to this discussion on each and every page involved, so everyone interested had almost a month to express their opinion. And you've still not expressed yours. 1exec1 (talk) 18:36, 23 October 2011 (UTC)
  • Merge — merge articles on single functions into articles for header or library when they clearly don't deserve an individual article. Jason Quinn (talk) 18:37, 31 October 2011 (UTC)
  • Please stop. A lot of this "reorganizing" that's going on looks to me to be wholesale WP:OR in the form of creating articles on non-notable or, at best, questionably notable topics. The one I've been annoyed by is 1exec1's renaming of Malloc to C dynamic memory allocation despite lack of clear consensus. I concede that it wasn't a particularly good article about malloc and that with the (too many) horrid code examples trimmed, the content has improved. But we've gone from an article on a topic I'm satisfied was probably notable (we can trace it back to dmr's 1973 malloc.c in early 4th edition Unix and its appearance in K&R 2nd ed.) to a phrase that while common enough, may or may not be notable as required by WP:GNG.
    What I've seen also is that 1exec1 seems determined to ignore objections and the need to get consensus. Was it just me, there on the malloc page, I wondered? No, it's not. This is a problem everywhere 1exec1 goes and I can see others stating their concerns, which also seem to go unheard. 1exec1 needs to go a lot slower and show more awareness that what's already here reflects consensus, that if he wants to make changes, he needs consensus and to accept that when someone has to tell that you that don't have consensus, you probably don't. Msnicki (talk) 01:38, 1 November 2011 (UTC)
Can you prove that this part " <...>wholesale WP:OR in the form of creating articles on non-notable or, at best, questionably notable topics" and this part " 1exec1 seems determined to ignore objections and the need to get consensus." are more than allegations?
What WP:OR articles have I created? C miscellaneous operations is the only article I created that has no support of WP:RS. It was created (actually moved from stdlib.h) because I wanted to gather some opinions of the Wikipedians before deciding what to do with that article, not because I though that should be the final version of the reorganization. The editors decided that the article should be deleted; I'm perfectly fine with that.
In the case of malloc, there were 3 editors for a move, you were the only editor against (there was one editor that opposed to the merge of alloc.h, but not to the move of malloc). You failed to directly respond to my comments saying that the actual scope of the article was not malloc. You simply said the article should be improved. You failed to respond to the fact that there was consensus for some move, though not necessarily the one I chose. You failed to respond to my comments saying that most of WP:RS group all C memory allocation functions under the name of memory management or similar, not malloc. Instead, you started to cherry-pick sources (UNIX manuals), say that one of my examples was not exactly correct (the first edition of K&R The C programming language, though I was talking generally and what you've said doesn't apply to the second edition) and talk about things not related to the particular dispute. I may as well choose to ignore things that are not directly related to the move discussion itself, that is, do not bring new points to the discussion or fail to bring an argumentated response to the current ones. Please stop accusing others when it is you who doesn't facilitate a proper discussion. 1exec1 (talk) 18:39, 1 November 2011 (UTC)

Links to an external reference

Hello,

The previous discussion (Talk:C standard library#Pages for each function and WP:NOTMANUAL) resulted to merging of more than 40 manpage-like articles to some summary articles. Since these summary pages had links to the manpage-like articles even before merge, in think that it would be a reasonable compromise to preserve links to reference material for convenience, even if Wikipedia does not host that material itself. In this way, the summary articles could be able to describe the C library contents to the fullest extent: having the criticism, history and similar material in the article itself and linking to an external site for the reference which is not allowed in Wikipedia. Here by saying reference I mean a factual reference, i.e. functions, their parameters, preconditions, postconditions, etc. which are useful when programming; I'm not meaning tutorials, how-to's which are useful only when learning how to program. For example how a page with links looks like, see here. Note, that the total number of links hasn't increased, because before the merging, the manpage-like articles had at least one link to an external reference. Having said that, there's already some disagreement not only about the format of these links, but about whether we need them at all. Hence I think we need to establish a clear consensus regarding the links to an external reference and then act accordingly. 1exec1 (talk) 11:50, 23 October 2011 (UTC)

I would at least link through a template. That makes it easier to change the formatting and reference used at a later date. We should consider linking to the articles now in Wikibooks, although they're not in a very good shape at the moment (increased visibility might change that though, and multiple external references can in turn be linked to from the those articles.) Otherwise "official" references (The Open Group?) or ad-free free-content wikis would seem appropriate targets. —Ruud 13:21, 23 October 2011 (UTC)
Direct link to list from example given: C mathematical operations#Function overview. If you’re going to make a common practice of the linking, maybe look at how it seems to be done with Category:Javadoc templates, including {{Javadoc:SE}} for example used on java.lang.
 As for formatting, I’d certainly avoid changing font sizes. I also dislike using monospaced fonts inline with ordinary non-monospaced English text unless they actually help make things clearer, but I expect not everyone would agree with me on this. Vadmium (talk, contribs) 13:58, 23 October 2011 (UTC).
You mean those small C, C++? As for monospaced fonts, I think function names and types deserve being in monospace, because e.g. '...such as abs, labs, div, and ldiv, are instead...' is really quite unclear. Or did you have something else in mind? 1exec1 (talk) 18:28, 23 October 2011 (UTC)
Yep I meant the small text for the links. For that monospace example, I hoped using italics would make it clear: “such as abs, labs, div, and ldiv, are . . .” Vadmium (talk, contribs) 14:19, 24 October 2011 (UTC).
I agree, templates can be very useful in such cases.1exec1 (talk) 18:28, 23 October 2011 (UTC)
By the way, could you mark you opinion with Support, Oppose or similar to make it clear whether a consensus is established? There are editors who disagree with this.1exec1 (talk) 18:32, 23 October 2011 (UTC)
I'm not sure if my (or other) comments here can be directly seen as supporting or opposing some (which?) position. Take them more as good advice/constructive criticism. —Ruud 08:37, 24 October 2011 (UTC)
  • Reservations I'm not ready to offer an opinion but will express some reservations. The linking at the given example is very unusual, and certain to attract negative views, particularly from those who regularly oppose linkspam. While convenience links can be convenient, why not have just one link to somewhere with an index of all the functions? Anyone actually needing a man page description of a function would have worked out how to find it long ago (Google if nothing better known). If there is a particularly good site with info on standard functions, add it to external links? Johnuniq (talk) 00:35, 24 October 2011 (UTC)
In that example it should be the function names themselves that should be hyperlinked. I wouldn't be in favour of having more than one link per function in the body of the text either. —Ruud 08:37, 24 October 2011 (UTC)
The problem is that the C++ language inherits the same functions from C, but the definitions themselves are somewhat different. If this wasn't the case we could easily do as in map (C++)#Overview of functions. 1exec1 (talk) 08:52, 24 October 2011 (UTC)
I agree, the current format is not only unusual, but has quite high negative impact on readability. However, I think that removing these links entirely is something too much, as not a lot of time ago lots of these functions (e.g. most in C string) had separate pages. Reducing the availability of detailed information to a mere link at External links is something too much IMO. Thus I'll try to find a solution that involves links to reference first. One thing to note is that this linking is limited to only one section.1exec1 (talk) 12:36, 24 October 2011 (UTC)

Several suggestions how we could improve the current formatting:

1)

or without <small>

2)

  • sinh - computes hyperbolic sine (references: C/C++)
  • asinh (C99, C++11) - computes hyperbolic arc sine (references: C/C++)

or without <small>

  • sinh - computes hyperbolic sine (references: C/C++)
  • asinh (C99, C++11) - computes hyperbolic arc sine (references: C/C++)

3)

or without mentioning C++

  • sinh - computes hyperbolic sine
  • asinh (C99) - computes hyperbolic arc sine

I think all of the above are much better than the initial ( example ) formatting. I personally like the first one. 1exec1 (talk) 12:36, 24 October 2011 (UTC)

Maybe it would be a good idea to explain what the links are and where they lead, rather than leaving it implicit? BTW it looks like the linux.die.net man pages are just rather old versions from the “Linux man-pages” project; http://man7.org/linux/man-pages/online/dir_all_by_section.html#man3 is closer to the source. Vadmium (talk, contribs) 14:19, 24 October 2011 (UTC).
I dislike the 1st and 2nd way of linking (they look like those click here links). The 3rd (4th actually) method is the style that is generally used on Wikipedia. The main problem is of course that we're then limited to a single link per function. I see two possible solutions to this:
  1. Link to the Wikibooks articles. In the the Wikibooks we can then link to two, or even more, additional external references, perhaps even from an infobox-like sidebar? (Advatages: increases the visibility of the C Programming Wikibook, requires us to complete the references by adding an articles for each function and improving the existing ones. Disadvantage: Requires us to complete the references by adding an articles for each function and improving the existing ones.)
  2. Make those links anchored to links to items in the References section, from where we can link to one, two or more external references.
—Ruud 14:41, 24 October 2011 (UTC)
After some experimentation, I agree that the last option is probably the clearest. Also, I've probably given C++ too much weigh, since actually not much C++ programmers use C stuff, which most of the time has C++y equivalents. Maybe one link to some C++ reference at the top of the function list would be enough. 1exec1 (talk) 22:03, 25 October 2011 (UTC)

Windows and the C library

I'm not sure about what to add there: I know there IS an implementation of it in Windows, and that critical security DLLs depend on it: so in a way, if you take out the C standard library DLL, you take down Windows. Moreover, some compilers (such as MinGW and old versions of Visual Studio) piggyback on it.

But I don't know the official stance of Microsoft about it: My best guess would be that it's not (longer) supposed to be used and that each compiler is expected to provide its own, but I have no citation on it. Medinoc (talk) 08:26, 19 October 2011 (UTC)

Move articles about C standard library from C *** to *** in C

The current titles of articles about C standard library (namely C mathematical functions, C file input/output, C program control operations, C character classification, C date and time operations, C dynamic memory allocation, C data types) are somewhat bizarre. I suggest to move these pages to *** in C versions, e.g. Mathematical functions in C. I think that doing a centralized discussion would be beneficial, because for consistency we should either move all pages or none of them.

The centralized discussion is made somewhat complicated because there are several ongoing discussions with intentions to split some articles. I think that this discussion are independent from them. 1) discussion about a split off of malloc from C dynamic memory allocation. 2) discussion about a split of C string to null-terminated string or similar and String handling in C/C string handling or similar: if the split discussion concludes that no split is needed, I do not suggest any moves, otherwise the target page (String handling in C/C string handling) should be selected according to the outcome of this discussion.

1exec1 (talk) 12:45, 2 November 2011 (UTC)

  • Oppose. These invented titles are all basically WP:OR. They may be common (like "sunny day in Florida") but there's no way to establish notability for these subjects as they mean only whatever anyone says they mean. Wikipedia is not intended to be a giant tutorial on WP:HOWTO use C, all nicely divided into nice chapters, each consistently named. This is an encyclopedia. For example, if, as 1exec1 concedes, there's nothing to talk about except malloc in the bizarre (his word, but on this, I agree) C dynamic memory allocation article, let's move it back to malloc, the name Ritchie gave it when he invented it. Msnicki (talk) 14:14, 2 November 2011 (UTC)
That's an absolutely inappropriate invocation of WP:OR. The article C (programming language) has a section named "Memory management", there is absolutely nothing in WP:OR that prevents us from spinning-off that section into a full article title Memory management in C. By analogy: article Netherlands has a section titled "Floods" and a spin-off article titled Flood control in the Netherlands. Your argumentation now basically boils down to the claim that the article on flood-control should be deleted, as being original research, and only an article on the Delta Works should remain. Also, I think you're putting words in 1exec1's mouth here, but he can comment on that himself. —Ruud 14:59, 2 November 2011 (UTC)
Msnicki, I see that you would like that article to be moved back at malloc, but lying is absolutely wrong way to achieve that. Can you tell when did I say that C dynamic memory allocation contains, or should contain only material about malloc? 1exec1 (talk) 16:30, 2 November 2011 (UTC)
Thank you for making my points. It's impossible to know what "C dynamic memory allocation" should contain because it doesn't have a clear notable meaning. Is this a survey of every published algorithm for doing this in C? Is this a tutorial on the topic? Who knows. You conceded that if we split out the part on malloc, there wasn't enough left for another article on your new subject here. Malloc is very clearly about malloc. We can establish notability for that subject. That's important here on WP.
And thank you also for making my point that you don't show much real interest in consensus; you'll pardon me for pointing out that when I get accused of lying, I don't get the impression that individual is trying very hard to be inclusive or accommodating or even very respectful. And I am not the only one with concerns you're ignoring. You gave pretty much the same brush-off to Deryck C. on your talk page; you weren't nasty to him but you also didn't appear to hear a word he was saying. Go slower and actually get consensus, don't just steamroller mass changes. Msnicki (talk) 16:51, 2 November 2011 (UTC)
Regarding my concession, you pulled the quote out of context. There's in fact less material on malloc as compared to everything else, that was clearly indicated at the talk page (look for a paragraph beginning with I don't think that this article discusses only Malloc as you seem to allege). As for accusation of lying, I am tired of the hypocrisy when you accuse me of failure to cooperate yet don't respond to valid points in the talk pages elsewhere. My further response can be very easily summarised using this quote from this talk page that you still haven't responded to:

<...> In the case of malloc, there were 3 editors for a move, you were the only editor against (there was one editor that opposed to the merge of alloc.h, but not to the move of malloc). You failed to directly respond to my comments saying that the actual scope of the article was not malloc. You simply said the article should be improved. You failed to respond to the fact that there was consensus for some move, though not necessarily the one I chose. You failed to respond to my comments saying that most of WP:RS group all C memory allocation functions under the name of memory management or similar, not malloc. Instead, you started to cherry-pick sources (UNIX manuals), say that one of my examples was not exactly correct (the first edition of K&R The C programming language, though I was talking generally and what you've said doesn't apply to the second edition) and talk about things not related to the particular dispute<...>. 1exec1 (talk) 18:39, 1 November 2011 (UTC)

I can't really discuss further until you respond to the above points without derailing the discussion. 1exec1 (talk) 20:36, 2 November 2011 (UTC)
(Thanks Msnicki for telling me I'm mentioned in this discussion) To be honest, I'm opposed to this mass-move from <***.h> to "C ***" from the outset, largely because the articles, even after being moved, were predominantly about stuff in the headers. The main reason the proposed (and to some extent the current) titles are unhelpful is that all these articles are about built-in functionality of the C language and its derivatives, but the article title gives the impression that it should include other methods of achieving them using C as well. Given that notability and original research are the main concerns here, moving the articles back to the header names is actually the most sensible solution, given that the functions covered by an article collectively have enough notability. (If they don't, the article shouldn't exist anywhere anyway.) Deryck C. 17:45, 2 November 2011 (UTC)
Thank you. I think that's a pretty good, guidelines-based analysis. We don't pick titles for new articles based on whether they'd be helpful. We decide based on whether we can establish notability. If there are particular headers that have undeserved articles, we should AfD them. But if we take them to AfD, e.g., Wikipedia:Articles for deletion/Stdlib.h, the standard there, too, should be notability, not whether some different, but questionably notable title would be far more wonderful. Msnicki (talk) 18:27, 2 November 2011 (UTC)
My response will consist of several unrelated ideas so I'll try to express them point by point:
  1. Re: scope of the articles. This is actually one of the purposes of this rename - to clarify the scope of the articles, so that not only standard stuff can be included. You can see that clearly in a discussion that led to this proposal. I actually didn't expect that such a minor change would be so controversial, so I even didn't bother to include scope as an argument. Yet it is an important one, since there exist a lot of notable material that is not really related to the C standard. For example, you can look at C string#Extensions to ISO C and C dynamic memory allocation.
  2. Re: notability and OR. I agree that all of my initial edits were made without clear guidance of reliable sources. However, after several disputes forced me to do quite a lot of research in RS, I think moving back to headers has many more problems. Most of the RS group all functions not by header, but by functionality, which is usually the same as headers, but not always. For example, we can look at the C99 standard: all sections are named in this format Mathematics <math.h>. K&R C programming language (2nd edition) doesn't use header names at all (e.g. Storage management), except in the appendixes. The C++ books don't emphasize headers at all when talking about the functionality inherited from C, for examples we can look at B. Stroustrup The C++ Programming Language (3rd Edition), B. Stroustrup Programming: Principles and Practice Using C++, C++ standard. I did what I could not to cherrypick, these are the most notable books I have.
  3. Much bigger problem with articles about headers is that we can't write an encyclopedic article about them, since reliable sources have only very little information about the header itself. Most of the time they include only a short mention about the header and then go on talking about the contained functions. Thus the real scope is not the specific header, but the functions contained within that header. Since there are a lot of RS that don't group the functions by header at all, I think it is not OR to do similarly. A relevant discussion has been developed at Wikipedia:Articles_for_deletion/Stdlib.h.
1exec1 (talk) 20:36, 2 November 2011 (UTC)
Okay, I understand you're skeptical of how one might write an encyclopedic article about a header, so let me explain how I would go about it. But first let me talk a little about notability.
The big hurdle in writing about anything on WP is establishing notability, which has a much more technical meaning here than most people expect from common usage. It's not enough that a topic seem notable or that it just seems like this would be a good way to break things up into a nice set of essays. Each topic has to satisfy the WP:GNG meaning there have to be secondary sources that actually take note of that specific topic. But that's all it takes. They don't have to offer long essays of the politics of why that header used all lower case, no Hungarian or whatever. When multiple writers devote whole sections to the same material, even if it is largely duplicative in the reporting, as long as it's not dismissible as, e.g., routine coverage of a press release, that gets you notability. (This, btw, is also the threshold that keeps out people wanting to use WP to advertise their latest wondergadget, supported only by their website; the answer to them is that they need to get other people to write about them first. If they can convince a couple reliable journalists that their products are notable, that goes a long way toward convincing us.)
I'm very much a deletionist, mostly because I like being able to come here and get verifiable information, which you don't get if you allow spam or allow people to think of WP as a great place to post useful essays. Case-by-case — and that's how we should look at notability — it seems to me there's no question we can establish notability of individual routines and headers. If we find a source talking about stdlib.h or limits.h or malloc(), we can be pretty sure they're about that particular, identifiable, notable thing. That means we can and should have an article on it, which probably will start as a stub and may stay that way for years waiting for someone to put the effort into making it something more than a stub. Otoh, where notability is a question, it does not follow that the problem can be solved with a more generic title; those articles should go or be merged.
Once notability is established, it's just basic research to fill in the rest. It's work, but I think it's fun. I pick the topics I work on to be ones where I already know something about the history to know what to go look for. But if I were to pick up working on one of the header articles, I would start by trying to identify the who, what, when, where facts which might distinguish this from a simple man page. I like filling in is the history. Computer scientists working in the C / Unix community in the 80s left fingerprints all over the place on Usenet discussing what they were doing and why and it's all been captured on Google. They also wrote lots of papers for USENIX or the Bell System Technical Journal. Sites like the Unix tree have archives of old builds. Can we establish who wrote it and when? What was in the earliest release? What did it do? What got added or changed over time? Were there any fights over performance (e.g., the BSD4.3 malloc) or security or standardization? Although the easiest material to fill in for a header file will always be just the man page stuff, that's not what WP is here for. If that's all you have on an otherwise notable topic, that's called a stub. We don't delete them, they just wait for someone with time to do the non-original but, I think, fascinating research. Msnicki (talk) 17:36, 3 November 2011 (UTC)
Alright. Nice story - I disagree with many of the points you brought up, let's ignore that for now - but would you be willing to demonstrate it ("show me the code"-style)? Pick one of the headers - I'd prefer it to be stdlib.h, but any one of them is fine - and expand it, beyond a one-line definition and list of function prototypes, in the way you propose. But, as you also point out above, that expansion should concern only the header file in question, not the implementation of functions whose prototype happen to be listed in that header file, but are properly part of crt.lib or some equivalent. My position is mostly based on the fact that I'm convinced this is not possible, demonstrate me wrong. —Ruud 18:16, 3 November 2011 (UTC)
The test of whether we should have an article is notability, not how much there is to say WP:TOOLITTLE or whether any particular editor is willing to put the effort into creating more than a stub WP:NOEFFORT. Not every objection or demand, including those not supported by the guidelines, has be met to unanimous satisfaction, especially where the objection has been answered but someone just doesn't like the answer. Msnicki (talk) 18:45, 3 November 2011 (UTC)
Repeating this doesn't make it true. You're clearly neither interested in improving the quality of encyclopedic coverage of the C programming language in Wikipedia, nor in having an insightful intellectual debate. I will stop wasting my time with trying to communicate with you. Goodbye. —Ruud 19:07, 3 November 2011 (UTC)
Okay, never mind what I say, let's consult the guidelines. From WP:N, "On Wikipedia, notability is a test used by editors to decide whether a topic can have its own article." Msnicki (talk) 21:14, 3 November 2011 (UTC)
Yet it is only a prerequisite. Can you show specific papers, books, etc. that allow us to write an article longer than several sentences? If not, can you provide specific reason, why the header can not be covered as a section of another article? 1exec1 (talk) 04:04, 4 November 2011 (UTC)
Your objection about length is irrelevant. From WP:TOOLITTLE, "There is no minimum or maximum length that qualifies an article, just the reliable sourcing of the information. Since nothing is in stone, articles can grow, shrink, merge, split, and change in all different ways over time. But once the subject becomes clearly notable, they do not disappear." But whatever the title, the hurdle is still notability. You need to establish notability for each title with reliable independent secondary sources as required by WP:GNG. That's impossible for "C dynamic memory management" but doable for malloc. This is not a "technical" objection. Notability is a pretty big deal on Wikipedia. If you want an article with a given title, you need WP:RS sources. For each and every proposed title, where are they? That's your burden; what have you done about that? Msnicki (talk) 05:19, 4 November 2011 (UTC)
As already been discussed in Wikipedia:Articles for deletion/Stdlib.h WP:TOOLITTLE is about current, not potential content. Sources and argumentation has been already raised at Talk:C dynamic memory allocation#Proposed split also below at the request section. Also you still haven't addressed the fact that most of WP:RS group all C memory allocation functions under the name of memory management or similar, not malloc. 1exec1 (talk) 16:40, 4 November 2011 (UTC)
I acknowledge and respect that your opinion is different than mine. Perhaps we should drop the stick. Msnicki (talk) 16:52, 4 November 2011 (UTC)
Well, who has which opinion is not important here I think (also WP:CON). What matters is what the WP:RS and Wikipedia guidelines say. So far you've ignored my requests to show what exact WP:RS and precise parts of Wikipedia guidelines that support your point. Also you didn't directly address exact supporting WP:RS that I have brought, so currently there's anything but a stalemate. In any case, I still think that moving C *** to *** in C is not related to this discussion, since they are both either appropriate or both are not. There's no arguments raised that differentiate between those two titles in this discussion. Let's say C *** is OR as you allege. Then *** in C is also the same OR, but has a clearer title. So it's a good idea to move to *** in C even if it is OR, because we'd have a clearer title until this discussion finishes, whatever the outcome is. 1exec1 (talk) 17:43, 4 November 2011 (UTC)
Request. Currently I am yet to see any valid arguments against the moves from C *** titles to *** in C which is technical in nature. The disagreement is mainly about whether these articles should be moved back to header names, which is not very dependent to the proposed moves (if we decided to move the articles back to header titles, it's not important whether the articles are at C *** or *** in C). Can anyone provide at least one argument against the proposed move?
Yes. You do not have consensus. Msnicki (talk) 04:58, 4 November 2011 (UTC)
That's not a valid argument. Per WP:CONSENSUS no consensus by itself is not a reason, the arguments used to build the consensus are.

<...>Consensus discussion has a particular form: editors try to persuade others, using reasons based in policy, sources, and common sense.<...>

No arguments concerning this particular move have been raised so far. 1exec1 (talk) 13:48, 4 November 2011 (UTC)
What do you mean, "no arguments"? You've gotten objections based on concerns of notability and WP:OR to your proposal and you haven't answered them. (And btw, if you do wish to answer them, you should do it with sources, not arguments.) You do not have consensus support. I don't see how this can be unclear. Msnicki (talk) 13:57, 4 November 2011 (UTC)
Sorry, I meant valid arguments. The sources for notability have been already posted:

For example, we can look at the C99 standard: all sections are named in this format Mathematics <math.h>. K&R C programming language (2nd edition) doesn't use header names at all (e.g. Storage management), except in the appendixes. The C++ books don't emphasize headers at all when talking about the functionality inherited from C, for examples we can look at B. Stroustrup The C++ Programming Language (3rd Edition), B. Stroustrup Programming: Principles and Practice Using C++, C++ standard.

However, these are not the only ones. There are lots of sources using *** in C wording: e.g. A.A.Puntambekar - Data Structures with C, S.G. Agarwal - Memory Management in C and C++, L. Ferres Memory management in C: The heap and the stack (edit: these probably fail WP:RS). All of these sources allow us to write an encyclopedic article about, in this case, dynamic memory allocation in C.
1exec1 (talk) 14:04, 4 November 2011 (UTC)
The fact that a phrase is common or generally descriptive does not make it a notable topic. "Memory management in C" can mean a lot of things and only sometimes does it refer to malloc or any other definitely notable topic. We don't have articles on non-notable topics. I see from your edit history you haven't spent much time in AfDs and it shows here; you need to spend more time understanding how notability works. It's not what you think. Please spend some time reading and thinking about the guidelines. Try to think about what they ask of us, not just how to get your way. Msnicki (talk) 14:39, 4 November 2011 (UTC)
1) I think I understand notability criteria well and that's orthogonal to my editing habits.
2) Please show specific parts of WP:N and/or WP:OR that are being violated.
3) I do not say that Memory management in C should contain only malloc. It will include whatever WP:RS say Dynamic memory allocation in C means, including realloc, free, calloc. Thus there are no issues with scope.
4) The following two WP:RS in addition to the already posted ones establish notability and remove any doubts of WP:OR for Dynamic memory allocation in C: S.G.Ganesh - Dynamic Memory Allocation in C, Dr. M.K. Sharma, Dr. M.P. Thapliyal - Concept of Computer and C Programming. 1exec1 (talk) 14:55, 4 November 2011 (UTC)
Obviously, you're entitled to your opinion. But the point is, there's a difference of opinion. Two of us have opposed based on WP:N and WP:OR and this means you do not have consensus support. I don't know how to be more clear. Msnicki (talk) 15:02, 4 November 2011 (UTC)
1) Consensus is based on arguments, not votes WP:NOTDEMOCRACY.
2) Please show specific parts of WP:N and/or WP:OR that are being violated, since so many WP:RS have been provided.
3) Please show WP:RS that base your choice of title and allow us to write encyclopedic article.
4) You repeatedly do not directly address or rebut the raised points. That's disruptive editing.
1exec1 (talk) 15:14, 4 November 2011 (UTC)
You're not helping yourself. Msnicki (talk) 15:38, 4 November 2011 (UTC)

Discussion, part two

Comment: This discussion raised a lot of issues which don't seem to be about choosing between C mathematical functions and Mathematical functions in C. It seems easy to separate problems about the topic's sourcing or notability from the way we arrange the words in the title. Is the issue of original research what's preventing us from discussing which of those two names is better? --Pnm (talk) 01:46, 8 November 2011 (UTC)

The proposal is problematic both because many of the titles appear to be impermissible WP:OR and because it seeks to rename a whole set of articles even though the issues are not identical in all cases. For example, a case might be made that "C standard I/O" is notable and suitable as a title, but probably only because it's so clearly a reference to <stdio.h>, which definitely is notable. The case is nowhere near as clear for "Mathematical functions in C" and some of the other titles, which could mean anything and invite open-ended essays. 1exec1 would have a better chance selling his proposal if he took it one article at a time and actually listened and responded to objections. He's not doing that and instead has been throwing out accusations of lying and hypocrisy, questioning others' good faith and making silly claims that concerns about notability or WP:OR aren't valid objections. I think his proposal is dead. Msnicki (talk) 02:59, 8 November 2011 (UTC)
I don't understand how Wikipedia:No original research relates to a choice between C mathematical functions and Mathematical functions in C. --Pnm (talk) 03:45, 8 November 2011 (UTC)
They're probably both questionable, if that's your question. But we don't move articles just because the proposed title is no worse than the one we have. WP:OTHERCRAPEXISTS is never a valid argument here on WP even if the "other crap" is merely the current title. Msnicki (talk) 03:54, 8 November 2011 (UTC)
Of course if we have two equally good titles we don't rename an article. But the proposed title is more natural than the old title. (See WP:CRITERIA for article titles.) The other part of WP:TITLE which refers to situations like this is WP:NDESC, which permits descriptive titles invented specifically for articles. The descriptive titles should be based on sources – so we should follow the sources about whether to use "mathematical functions" or "math library," say – but it doesn't suggest that the entire title phrase needs to come verbatim from a secondary source. --Pnm (talk) 04:23, 8 November 2011 (UTC)
Whether the proposed title is more natural is a matter of opinion on which we differ. Msnicki (talk) 04:29, 8 November 2011 (UTC)
Relevant sources are the following (copied from the stdlib.h deletion discussion). Covers pretty much every title, so no WP:OR. I think I'll just open WP:RM and ask for a speedy move. One ignorant editor shouldn't be a problem.
  1. Tony Crawford, Peter Prinz -- C in a Nutshell (ISBN 0-596-00697-7) : §15 introduces the headers, each with a very concise list of what functionality (not functions) is contained; §16 talks about each group of functions individually. Various bits from stdlib.h are assigned to Mathematical functions, Multibyte characters, Converting Between Numbers and Strings, Searching and Sorting, Dynamic Memory Management, Process control.
  2. Peter Prinz; Ulla Kirch-Prinz -- C pocket reference (ISBN 978-0-596-00436-1): No analysis of headers at all (they are listed though in §1.15). The content of stdlib.h is assigned to §1.18. Mathematical Functions, §1.20. String handling, §1.21. Searching and Sorting, §1.23. Dynamic Memory Management.
  3. Brian Kernighan, Dennis Ritchie -- The C programming language (2nd edition, ISBN 0-13-110362-8): No analysis of headers, except in Appendix B Standard Library. The content of stdlib.h is assigned to §2.7 Type Conversions, §7.8.4 Command Execution, §7.8.5 Storage Management, §7.8.7 Random Number generation.
  4. Herbert Schildt -- C/C++ Programmer's Reference (3rd edition, ISBN 0-07-222722-2): No analysis of headers at all. The content of stdlib.h is assigned to §11. The Dynamic Allocation Functions and §12. Miscellaneous Functions
  5. The C++ standard: No analysis of headers at all. The content of stdlib.h is assigned to §18.5. Start and termination, §18.10. Other runtime support, §20.6 Memory, §21.7 Null terminated sequence utilities, §25.5 C library algorithms, §26.8 C [numerics] library.
1exec1 (talk) 08:39, 8 November 2011 (UTC)
I understand you're frustrated, even exasperated. Please try to be civil. --Pnm (talk) 19:43, 8 November 2011 (UTC)
Actually I'm not frustrated, I'm just stating the truth while trying not to spend more time. How else could you explain these diff, diff, diff? Not the only occasion. Doesn't matter now, I don't want to open this again.1exec1 (talk) 20:50, 8 November 2011 (UTC)
Pot. Kettle. Black. On this one page, you've attacked me with charges of lying, hypocrisy, disruptive editing, ignorance and not listening. When I asked you to stop, you accused me of trolling. Msnicki (talk) 21:06, 8 November 2011 (UTC)
Per WP:NPA#WHATIS accusation is not a personal attack unless it is baseless. I'm not further interested in this discussion. Peace. 1exec1 (talk) 21:51, 8 November 2011 (UTC)
Seriously, both of you. Please lay off each other. Wikipedia is a big room with lots of other people in it. If you need to debate each other, take it to your talk page. Or ask for some assistance. But for the sake of the rest of us, in the interest of improving the encyclopedia, please keep this page on topic. --Pnm (talk) 22:25, 8 November 2011 (UTC)
Sorry for being patronizing. I could have made the point without the first sentence. --Pnm (talk) 03:59, 9 November 2011 (UTC)

Move request through WP:RM

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: pages not moved, although certainly no prejudice against re-requesting page moves individually. Arbitrarily0 (talk) 03:22, 22 November 2011 (UTC)

– (note: C standard library is not up for move. It just hosts this discussion)
The current titles are quite bizarre, *** in C versions are better. The moves are pretty technical in nature, should have been uncontroversial, but this generated very extensive discussions above, where one editor apparently disagrees and doesn't listen to arguments. He argues that WP:OR and/or WP:N applies to the titles even though multiple WP:RS have been brought into the discussion. Also, per WP:Articles for deletion/Stdlib.h one his preferred destination for the content has just been deleted. Thus I think this should be a speedy move. Relevant references:

  1. Tony Crawford, Peter Prinz -- C in a Nutshell (ISBN 0-596-00697-7) : Section names: Mathematical functions, Character Classification and Conversion, Dynamic Memory Management, Date and time, Process control.
  2. Peter Prinz; Ulla Kirch-Prinz -- C pocket reference (ISBN 978-0-596-00436-1): Section names: §1.16. Input and output §1.18. Mathematical Functions, §1.19. Character classification and case mapping §1.20. String handling, §1.23. Dynamic Memory Management.
  3. Herbert Schildt -- C/C++ Programmer's Reference (3rd edition, ISBN 0-07-222722-2): Section names: Mathematical functions, The Dynamic Allocation Functions, Time, Date, and Localization Functions. 1exec1 (talk) 09:34, 8 November 2011 (UTC)
Ah, yes, forgot to change that. I agree with Date and time functions in C and Input and output in C.1exec1 (talk) 10:53, 8 November 2011 (UTC)
  • question Shouldnt these article names reflect that its operations with the C standard library? Christian75 (talk) 13:33, 8 November 2011 (UTC)
This proposal is also about expanding the scope of the articles. Currently there's nowhere to put notable non-standard stuff. That's a problem, since we already have a lot of important non-standard functionality covered in C string and C dynamic memory allocation. 1exec1 (talk) 15:50, 8 November 2011 (UTC)
  • Oppose. This is the exact same proposal as above with the same problems. 1exec1's argument in favor amounts merely to repetitive assertion that no one else's objections matter. There certainly isn't any other argument in favor; these names aren't better and invite open-ended essays on general topics. The current titles are flawed as well, but the proposed new titles aren't better. Further, a proposal for an en masse change makes it difficult to take each article case-by-case to seek out consensus on each. For example, I would support renaming "C mathematical functions" to "C math library", "C file input/output" to "C standard i/o" and "C dynamic memory allocation" back to "Malloc" but these aren't on the table. Msnicki (talk) 14:21, 8 November 2011 (UTC)
I find your point interesting given your repetitive disregard of any of my arguments that address or rebut your objections. We've already discussed in length, I do not think I have anything to add. 1exec1 (talk) 16:22, 8 November 2011 (UTC)
  • Oppose Bizarre is not a valid argument in Wikipedia. We should go by what people expect and the old names are closer to that. If something more correct is wanted I'd have put library after C and replaced operations with functions to get things like "C library date and time functions". The base standard in Wikipedia is WP:COMMONNAME unless there is a very good reason for doing otherwise. Dmcq (talk) 16:28, 8 November 2011 (UTC)
Exactly. We should reject this all-or-nothing proposal. I think there's an opportunity to improve these titles but I think we need to take them one-by-one, rather than simply !voting on a big package deal. For each article, we should start by collaborating on the talk page just to get a list of possibilities out on the table. As Linus Pauling famously observed, if you want a good idea, "first you start with a lot of ideas and then you throw away the bad ones." Who knows what great ideas are out there and what the opportunity might be to satisfice some points of view you hadn't even thought of. I believe in WP:CONSENSUS even when the outcome is different than I might have chosen; it's a process that works. But I would like to request, please, that we start by assuming good faith. Msnicki (talk) 17:28, 8 November 2011 (UTC)
I guess there would be a bit of a problem with 'library' as many facilities are just provided by the include file. I don't think there is a need to say operations instead of functions even so. So I'd just say 'C date and time functions'. Dmcq (talk) 18:15, 8 November 2011 (UTC)
  • Information I did a google search of "C input output" and got 2.7 million hits and a search of "input output in C" got 87000. Dmcq (talk)
These proposed names seem to be more consistent with existing articles titles that need to be made more specific to be unambiguous (e.g. Generics in Java, Flood control in the Netherlands, Convexity in economics). —Ruud 18:13, 8 November 2011 (UTC)
You raise a very good point. I've checked the other titles and google returns either many more hits for the old title or only a few more for the new one. If paired with WP:COMMONNAME and WP:TITLE consistency criteria, this is a very strong opposing argument. 1exec1 (talk) 23:09, 8 November 2011 (UTC)
  • Comment Why not just add a redirect from these new names to the current names? IRWolfie- (talk) 16:09, 11 November 2011 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Move?

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: no consensus for move. Favonian (talk) 19:55, 9 December 2011 (UTC)

C standard library → C Standard Library –

  • Support as nominator. 1exec1 (talk) 16:33, 2 December 2011 (UTC)
  • Oppose. I'm not convinced there's a conventional capitalization for this phrase; a lot of the time when each word is capitalized in any sources, it's probably because it's a heading and that particular author has a convention of capitalizing all words in a heading. For example, in K&R, 2nd edition, it's "Appendix B. Standard Library" in the Table of Contents but all lower case in the text, e.g., on p. 3, "The standard library functions are only called explicitly, so they can be avoided if not needed." Our convention on Wikipedia is that we only capitalize the first word in most cases and I think that's what we should continue to do here. Msnicki (talk) 23:47, 2 December 2011 (UTC)
  • Oppose WP:COMMONNAME says in the intro proper nouns, please read WP:CAPS too. The ISO/IEC 9899:1999 specification[1] does not use capitalization (one place it does in a footnote) and it is the reference in this article for the title. Christian75 (talk) 00:09, 3 December 2011 (UTC)
Isn't C Standard Library a proper noun with specific designators? The reference you mentioned doesn't contain phrase C standard library at all as far as I can tell. 1exec1 (talk) 01:45, 3 December 2011 (UTC)
It's not capitalized in that spec. From page 167, "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static storage duration." and "Thus, a signal handler cannot, in general, call standard library functions." See also pages 247 and 499. Msnicki (talk) 02:52, 3 December 2011 (UTC)
Yes, standard library is not capitalized. I'm not sure whether standard library and C standard library is the same thing though. The proper nouns article has several examples where such distinction is emphasized, e.g. The university has a school of medicine., The University of Hawaii at Manoa has a school of medicine, <...>. So, it this case standard library means any standard library, C Standard Library means the particular library (as a standard) of the C programming language. That's how I interpret the proper nouns article. Though I think we need an expert opinion here. 1exec1 (talk) 12:20, 3 December 2011 (UTC)
They didn't say "a standard library", they said "the standard library". And it starts off on page 1 stating, "This International Standard specifies the form and establishes the interpretation of programs written in the C programming language.", so we know they weren't thinking about a library for FORTRAN. You're grasping at straws. Msnicki (talk) 16:01, 3 December 2011 (UTC)
Please read proper nouns. The following examples The university has a school of medicine., The University of Hawaii at Manoa has a school of medicine, <...> both refer to the same instance of an university. Similarly, the cited reference has no need to capitalize the standard library, thus such usage is irrelevant when deciding whether C standard library is a proper noun or not. 1exec1 (talk) 17:13, 3 December 2011 (UTC)
What part of "They didn't say "a standard library", they said "the standard library"." seems confusing? Msnicki (talk) 17:21, 3 December 2011 (UTC)
  • Question. Is C standard library proper noun or not? 1exec1 (talk) 17:15, 3 December 2011 (UTC)
  • Weak oppose. Third party sources are more important than the standards themselves. Anyway, I don’t think there are any clear conventional names for the library. It looks like some sources write C Standard Library in capitals, others write it in lower case, and others don’t go out of their way to use either form. My gut feeling is standard C library (rearranged wording) is more common anyway, and Google tends to support this. One reference book I flicked through just uses descriptive terms such as the standard C I/O functions, C/C++ function library, C/C++ standard library, and standard function library. Vadmium (talk, contribs) 13:10, 4 December 2011 (UTC).
  • Undecided This needs a more thorough analysis of the available literature to see whether this is significantly more commonly used as a proper noun, or as Vadmium suggest in the alternative form "standard C library". I can't possibly decide without statistics. A simple Google search won't suffice due to for example the issue with capitalization of headers that Msnicki describes. —Ruud 22:10, 4 December 2011 (UTC)
  • Oppose until knockout reasons are available Whatever the merits, such a move would just invite venting from the MOS titles crowd. Why bother? There should be excellent sources supporting a move, before it happens. Johnuniq (talk) 02:35, 5 December 2011 (UTC)
  • Oppose - I don't have an answer but, 1exec1's proper noun question is what the decision to rename should be based off. For the purposes of capitalization on WP, it is of little importance how the term is capitalized in sources - those sources are probably using a different style guide. I've read Proper noun and am quite familiar with the C standard library but am still reluctant to make a call on this. I have observed, however, that there is a tenancy for these disputes to resolve to lower case when the topic is not clearly a proper noun. See Talk:Physical_Layer#Requested_move.2C_multiple for instance. --Kvng (talk) 14:49, 6 December 2011 (UTC)
  • Uniformity I vote for uniformity. I don't care what you name all the article, but I do care about them ALL having a similar naming format, including this article name. Redirects will solve all other issues. Come up with some naming formats, vote on it, and move on down the road. • Sbmeirow • Talk • 16:00, 6 December 2011 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Error handling

A bit about error handling was removed saying it was glibc specific. It does mention glibc but the problem is general with the C standard library. It seems very odd to me that there is not more about the problems of error handling. The problems of thread safe handling should also be dealt with in this context, particularly in how it affects the handling of errno. Dmcq (talk) 11:39, 4 February 2012 (UTC)

Licence?

Unlike its sibling articles GNU C Library and uClibc, this article does not mention any licence? Why is that? Swenkman (talk) 21:27, 9 August 2012 (UTC)

It's an interface rather than a specific implementation. Interfaces aren't covered by copyright. — Vano 23:47, 17 August 2013 (UTC)

Organizing the buffer overflow vulnerabilities

I noticed that this section does not mention secured alternatives to vulnerable functions in the C std lib. Since this list is relatively long and fairly well documented, I think it would be useful to create a table in this section with the families of vulnerable functions, a summary of their specific vulnerabilities, and preferred functions. A starter list:

  • strcpy vs. strncpy (vs. strlcpy)
  • strcat vs. strncat (vs. strlcat)
  • sprintf vs. snprintf, vsprintf vs. vsnprintf
  • gets and scanf vs. fgets
  • strtok vs. strtok_r could also be discussed in the next subsection, on thread unsafe functions, for example

→ozhu量 (talk·contribs) 02:22, 11 March 2014 (UTC)

That would be good additions to the C standard library § Buffer overflow vulnerabilities and C standard library § Threading problems, vulnerability to race conditions sections, and you're more than welcome to edit the article. Of course, as we know it should be backed with a few references. — Dsimic (talk | contribs) 16:45, 13 March 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:C_standard_library/Archive_2&oldid=1136953470"