Talk:Null-terminated string

Single page for C string functions

Based on Talk:C standard library#Pages for each function and WP:NOTMANUAL

The following pages essentially discuss the same topic of C string functions: string.h, memset, strcpy, strlcpy, strcat, strrchr, strcspn, ctype.h, strcmp, strlen, memccpy, mempcpy. I propose to cleanup these pages by removing the material that fails WP:NOTMANUAL and by merging the remains into C string.1exec1 (talk) 23:29, 8 October 2011 (UTC)

memset , memcpy, and mempcpy don't operate on C strings (that is, NUL-terminated strings). They operate on buffers with a length specified by one of the arguments. However I agree that there should not be one function per page. Jeh (talk) 04:33, 11 October 2011 (UTC)

I am unsure myself what to do with these functions. They do not really belong to C string, that's a fact. On the other hand, IMO they are not significant enough to warrant a separate page, and even if we chose to create one, there's hardly a good descriptive name for it. I myself tried to think of one, but all of them fit better for functions like malloc, e.g. C memory handling, C memory operations, etc. Going further, mem* functions are in the same header as str* functions, and most of the references I could find, e.g. cplusplus.com, cppreference.com, the C standard, preserve such grouping. Thus I think we wouldn't do a big mistake by sticking with established sources. Given these arguments, I think it's a good option to merge mem* to str*. That said, if you've got a sensible alternative, I'd happily reconsider.1exec1 (talk) 09:10, 11 October 2011 (UTC)

If some page is merged into C string , then we are unable to see the content of that page.:How can one read the information of that page after merging?

Sagar tikore (talk) 06:58, 11 October 2011 (UTC)

The content wouldn't disappear anywhere, just that it would placed in this article, not these separate articles.1exec1 (talk) 09:10, 11 October 2011 (UTC)

Instead of merging the functions in C string we can merge them into string.h

Asmita yendralwar (talk | contribs) 07:58, 11 October 2011 (UTC)

I don't think this would be a good option since it would be inconsistent with other pages discussing C standard library, e.g. C memory operations, C input/output.1exec1 (talk) 09:10, 11 October 2011 (UTC)

I agree with merging all of string.h into this page (there is a table already there) and removing all the trivial pages for the individual functions and changing them to redirects. However some pages with more information, in particular the strlcpy page, need to be preserved (this page contains a bit of history and political intrigue which is interesting but would bloat this page and make the table hard to read). The mem functions should be merged here as well, they are part of string.h and often are used to manipulate c strings.Spitzak (talk) 19:40, 13 October 2011 (UTC)

I also agree to merge all string.h here. Yogesh.rathod07 (talk) 06:40, 17 October 2011 (UTC)

I did a few modifications. In particular I dupliated the old string.h table and text here, it seems to be more accurate and carefully checked. In particular it lists some of the alternative functions which otherwise we lost. I also restored the page for ctype.h as I was under the impression this was to be divided up by header file (and also that file is not really dependent on null-terminated strings). I also restored the gets and strlcpy pages as they had significant text describing historic details and are referred to often from other wikipedia articles. Hope this is all ok.Spitzak (talk) 02:40, 19 October 2011 (UTC)

Oops it looks like I deleted all the external links to C/C++ documentation pages. Probably should be restored.Spitzak (talk) 02:54, 19 October 2011 (UTC)

strlcpy

I'm going to replace this page with a redirect again. The consensus was to merge all functions, that consist from material failing WP:NOTMANUAL and strlcpy falls into this group of pages. The only section that can be preserved somewhere is Criticism. However, I think we should can delete even that material, because it fails WP:NOTABILITY by not having WP:RS to back up the text. The already provided references are not WP:RS because of WP:SPS.
Going further, the page is imported into Wikibooks at b:C Programming/C Reference/nonstandard/strlcpy, so there absolutely no justification to keep anything failing Wikipedia guidelines here, when the content can be further improved in Wikibooks. 1exec1 (talk) 12:28, 19 October 2011 (UTC)

The criticism is backed by direct quotes from the maintainer of glibc posted on the official glibc mailing list. There was more but it is repeatedly deleted, because of a desire to obfuscate the exact guilty party and to try to claim the argument actually has merit. strlcpy is often mentioned as a indicator of misguided design in Linux and is thus a subject people will look for. I do not think whitewashing this story is good for Linux or for any of the involved parties.Spitzak (talk) 14:38, 19 October 2011 (UTC)

I'm not trying to whitewash or anything. I'm just saying there's not enough notable material to warrant a separate article, especially when strlcpy is not a standard function. That's not to say that we must delete that material - a better idea would be to merge the important bits to C string. In this case, we can create a new section called Extensions, move all the non standard functions there, and to place criticisms and other relevant stuff there. 1exec1 (talk) 16:58, 19 October 2011 (UTC)

While I personally agree with merging the page, you stated that you were going to merge the page but you didn't even do that before blanking it. The best practice according to WP:MERGE is to first obtain consensus, and actually merge the page before redirecting. I'm going to remove the redirect now because clearly the C string page does not cover all of the useful information in the strlcpy page. At the very least, the criticism of strlcpy needs to be addressed before this article can be redirected there. YumOooze (talk) 04:57, 22 October 2011 (UTC)

I think I have addressed your concerns.1exec1 (talk) 12:17, 23 October 2011 (UTC)

There is a lot of books which describe strlcpy, take a look at google books - the article has not been merged - must of the content has been removed with the argument that it violate WP:NOTMANUAL - I think the Section "Usage" could be rewritten by a few edits so it didnt "violate" WP:NOTMANUAL. And I dont understand why you removed this with the statement that it isnt noteable that e.g. Linux Kernel has ported the function - the kernel can not use the standard C library as you may know. I am going to remove the redirect again (until the page has been merged into this article) Christian75 (talk) 15:35, 23 October 2011 (UTC)

Do you wan't to say that all these thousands of functions that are in the Linux kernel deserve a page? Can you find a secondary WP:RS which justifies the inclusion as per wikipedia notability criteria? 1exec1 (talk) 17:53, 23 October 2011 (UTC)

In any case, the current consensus is to merge. See this discussion. As you can see, 5 editors (User:strcat, User:Vadmium, Ruud, Michael, User:1exec1) are for the merge, 2 users against (User:Spitzak, User:Christian75) (please fix if I'm wrong). So I have strong reason to undo your changes. Please establish new consensus before reverting. 1exec1 (talk) 18:14, 23 October 2011 (UTC)

Maybe there was a consensus for the idea of merging many articles but judging my the noise on my watchlist I dunno if there is much consensus for this particular merge from strlcpy into C string. How about something in between like renaming as strlcpy and strlcat? Sources and Wikipedia references seem to group them like that anyway. Vadmium (talk, contribs) 10:19, 24 October 2011 (UTC).

strcpy

I am going to replace this page with a redirect again. Almost all content fails WP:GNG, because the only secondary source I could find, that supports the material, is man pages, which is not WP:RS. The remaining is already at C string. Since there has been no recent attempt to fix these issues, except one editor who reverts page blanking, I assume that there is no genuine interest in the article.

I will not bring the article to WP:AFD because there is no intent to delete the page proper. Undoable action should be discussed in the talk page (see WP:AFD, specifically For problems that do not require deletion, including <...>, be bold and fix the problem or tag the article appropriately'). 1exec1 (talk) 13:29, 26 October 2011 (UTC)

strcat

I am going to replace this page with a redirect again. This page is in exactly the same situation as strcpy. Almost all content fails WP:GNG, because the only secondary source I could find, that supports the material, is man pages, which is not WP:RS. The remaining is already at C string. Since there has been no recent attempt to fix these issues, except one editor who reverts page blanking, I assume that there is no genuine interest in the article. 1exec1 (talk) 13:29, 26 October 2011 (UTC)

Have you tried a search with google books? I could find a lot of secondary sources to the article a minute ago - but it takes time to insert the refs. I think its a shame to delete it (I know you "merged" it, but the content didnt move with it). There exsist a lot of sources for strcat at google books "strcat buffer overflow" at google books Christian75 (talk) 17:50, 26 October 2011 (UTC)

You mean those all programming books/manuals? They do not constitute significant coverage as per WP:N, because if we remove the 'how-to use strcat' portion of that material, only a very limited factual mention is left. As per WP:N, you must find a third-party reliable source in which strcat is one of few major subjects. 1exec1 (talk) 19:55, 26 October 2011 (UTC)

Please, read the WP:N again, especially the section you quote significant coverage which says "Significant coverage is more than a trivial mention but it need not be the main topic of the source material." Christian75 (talk) 18:47, 28 October 2011 (UTC)

Show specific examples of books about limits.h and then we can talk what fails WP:N and what doesn't. 1exec1 (talk) 09:36, 29 October 2011 (UTC)

character vs byte

I think we should name characters as characters since these functions are for character string manipulation. I agree that there's an issue with multi-byte characters, but using bytes doesn't completely remove the source of confusion either, as the reader still must know that there exist non single-byte characters. What if we changed bytes back to characters and added a notice that str* functions operate on single-byte characters?1exec1 (talk) 19:05, 18 October 2011 (UTC)

Saying "it only works on the one-byte characters" is wrong, because the string operations will work on the individual bytes that make up parts of multi-byte characters (for instance you can count the number of characters, assuming no bad encoding, by counting the bytes that don't start with 10 binary, thus there are useful operations you can do working with the bytes). The proper term for the units it operates on is "whatever your C compiler means when you say 'char'" but that is hard to read, looks like the word 'character' misspelled, and 'byte' is probably a much more popular term. The C99 documentation is technically correct because they define the word "character" as being "char", but that is not how the word "character" is defined in any wikipedia article about text.

The main problem is that there are a lot of programmers out there who are just smart enough to do horrible things when they think that strlen() has to return the 'number of characters'. If they were a bit stupider we would be ok because they would not get anything to work. But there seems to be an overlap, perhaps best defined as 'idiot savants' or something, where they will actually write working, but horrific complicated code because they took the word "character" literally. These code writers are probably the biggest impediment to getting Unicode to work. There are active attempts to clear up the documentation, such as the BSD man pages which I was quoting, but there remains a huge amount of legacy documentation, including stuff from standards organizations. Anyway I see no reason not to have Wikipedia use modern notation.Spitzak (talk) 02:05, 19 October 2011 (UTC)

Ok, I agree. C++11 uses byte string to name single byte character strings, so I think it's a good idea to stick with it. 1exec1 (talk) 02:26, 19 October 2011 (UTC)

Null-terminated string

Shouldn't this article be at located at null-terminated string (or NUL-terminated string)? And primarily focus on null-terminated strings instead of C's string library? —Ruud 00:21, 19 October 2011 (UTC)

There's actually not much to say about null terminated string itself apart from the definition. Everything comes down to the operations that are defined on these strings, and the properties of these operations. C string library is the most widely used interface to these operations, so the attention to it seems reasonable to me. 1exec1 (talk) 01:41, 19 October 2011 (UTC)

You could also say a few other things. I haven’t really read the article :P but perhaps a comparison with other ways of storing strings and its relative strengths and weaknesses; languages and other applications where it is used? Vadmium (talk, contribs) 07:55, 24 October 2011 (UTC).

There is a comparison with a leading length at the start of the article!

Okay, so there is in the history section. And there’s more at String (computer science)#Representations. Vadmium (talk, contribs) 10:55, 24 October 2011 (UTC).

I would have to disagree with that. One can easily discuss the asymptotic complexity for various operations on null-terminated strings in terms of abstract functions. In my opinion this article should either be split into an article on null-terminated strings and an article on "Strings in the C programming language", of the latter should be more clearly made into a sub-section of an article whose primary topic is null-terminated strings. —Ruud 13:43, 24 October 2011 (UTC)

I agree with the suggestion to split the article. 1exec1 (talk) 14:22, 24 October 2011 (UTC)

Requested move

C string → Null-terminated string – Common and language-neutral name. —Ruud 13:55, 24 October 2011 (UTC)

how is the term C string not neutral?--199.91.207.3 (talk) 17:35, 24 October 2011 (UTC)

I would conjecture that the terms "C string" and "Pascal string" are mostly used by C programmers interfacing with libraries developed for different ABI's, while computer scientists and programmers from other languages would prefer to use the more descriptive terminology "null-terminated" and "length-prefixed" strings. The former already requires you know that C uses strings which are terminated by a null character and Pascal uses strings which are prefixed by their length, while this is self-evident with the latter. —Ruud 20:59, 24 October 2011 (UTC)

I think the term "Pascal string" means a 1-byte prefix length, not just the fact that a length is stored.Spitzak (talk) 23:50, 24 October 2011 (UTC)

True. So a Pascal string would be a particular kind of length-prefixed string. If we would have an article on that topic (which I don't believe we have at the moment), it would likely discuss all kinds of length-prefixed strings, not just 1-byte-length prefixed ones. —Ruud 00:58, 25 October 2011 (UTC)

I would support either a move to Null-terminated string, and/or integration with String (computer science)#Null-terminated, especially if the C stuff is to be a separate article. Vadmium (talk, contribs) 05:14, 25 October 2011 (UTC).

Maybe we can move the article containing the remaining C stuff to C standard string functions or similar title? 1exec1 (talk) 18:15, 29 October 2011 (UTC)