I think namespaces are still a worthwhile approach, especially if we
ever decide to post code that isn't part of a libc implementation [I
mentioned libclc in my other reply]

A hierarchial namespace is discouraged on wikipedia for a reason, but i
tihnk that reason maybe doesn't fit well here.

How about we [i guess by 'we' i mean 'you'] set it up like the
following?

Standard_Library/string.h [place to put explanations of constants and macros,
and the header file code itself]
Standard_Library/string.h/strcpy

[the current strcpy article moved to Standard_Library/string.h/strcpy
and so on]

[quoting User:Random832 in <slrne1s8fh.108a.random832@random.yi.org> in comp.lang.c on 03:28, 20 Mar 2006 GMT]

The main advantage of the approach that you suggest is that it avoids the incorrectly auto-capitalised first letter, a minor disadvantage is that it doesn't handle identifiers defined in multiple files - off-hand NULL's the only case I can think of where that applies. I think that having the titles of all standard functions, header files, macros, and other identifers, as well as all operators and keywords, in the same "pseudo-namespace", without being preceded by a "directory string" is preferable on balance though; and that the approach that you suggest could be useful for non-standard libraries. --Netocrat 00:55, 21 March 2006 (UTC)

So, basically, you mean have names like Standard Library/strcpy? ok. We could also have the short names like Strcpy redirect. --Random832 02:31, 21 March 2006 (UTC)

Actually I meant to leave things as they are but I can see how you interpreted what I wrote the way you did. Hold off on moving things until we find a consensus on this. There are advantages to what you suggest (in particular proper capitalisation) but also disadvantages (much longer url; title includes extra unnecessary wording). Jannis, Flash, and anyone else - comments/preference? --Netocrat 03:41, 21 March 2006 (UTC)

OK, I've thought this through a lot more along with capitalisation, and what I've come to is: your original idea is a good one, with the redirects to catch GeSHi highlighting links. Let's name the top-level article "C standard library" though to follow the convention of first-letter-capitalised-rest-lowercase and to make it clear to anyone directed to articles from off-site GeSHi highlighting links that they're looking at a standard C function rather than an OS-provided or third-party function. I think it's a good idea because it makes sense to show the hierarchy for easier reader navigation, and if we enable subpages in the main namespace then we get wiki-generated navigation links top-of-page looking like this (for an article titled: C standard library/string.h/NULL):
< C standard library | string.h

Although NULL occurs in multiple headers, if we redirect we can get something reasonably clear looking like this:
< C standard library | string.h
(Redirected from C standard library/stdlib.h/NULL)

This also allows for more sensible structuring of the K&R2 solutions and the (mostly empty) C tutorial as e.g.
K&R2 solutions/Chapter 1/Exercise 1
C tutorial/Chapter 1/Exercise 1
without name clashes or need for an actual new namespace.

To me it also makes sense to apply this structuring to the rest of the wiki's content as long as the hierarchy doesn't get deeper than about three levels and non-node articles contain a complete and readable index of the sub-nodes. So we could have: "C language/Control keywords/if-else" to which both "if" and "else" redirect; "C language/Terms/Null pointer constant" to which "Null pointer constant", "null pointer constant" and "NPC" redirect; "comp.lang.c/Portability attitude" to which "Portability and ANSI C compliance" and "C writings/Portability" redirect, "comp.lang.c/Posting guidelines" to which "Introduction to comp.lang.c" redirects; as well as "C resources/IDEs" and "C resources/Compilers".

It is also possible to turn off auto-capitalisation of the first letter of articles, which makes sense to me. We can't (as yet) avoid the underscore=>whitespace conversion problem, but we can at least avoid having memcpy automatically translated to Memcpy and having to include a template explaining the problem. I'll make those two configuration change suggestions (i.e. subpages in main talkspace and no-auto-cap of first letter) on the customisation talk page. --Netocrat 15:33, 30 March 2006 (BST)

Imported from Talk:Clc_libc

I've considered how best to structure and integrate the library/language/reference manuals with portable implementation code, and I like the approach that User:Jannis started by placing implementation code inline with each function's reference page. I figure we can continue that approach, using a convention of quarantining all non-portable parts of an implementation into identifiers prefixed with _np. These could be comprehensively listed on a single page - I've created Non-Portable Standard Implementation Components for that purpose.

I don't know how that fits with your (User:Random832 that is) ideas and what role this talk page's counterpart could play in that process, but here are some pages that show how we could structure things. Start from strlen which is categorised under Category:string.h, for which an article also exists: string.h. All of these exist under Category:C library reference manual. The non-portable identifier _np_size_t in the string.h implementation has been documented at Non-Portable Standard Implementation Components.

One thing that I like about this approach is that we end up with a comprehensive list of what can't be portably implemented in the standard library. So how does that fit with your ideas? --Netocrat 01:20, 20 March 2006 (GMT)

I think it's a good idea to add that non-portable page. Otherwise one would have had to reinvent it every time. --Jannis 10:11, 20 March 2006 (GMT)

I think starting the identifiers with a double underscore would be better since an underscore followed by a lower case letter is not reserved for all uses. It saves having to worry about whether it is an acceptable usage or not. --Flash Gordon 20:22, 20 March 2006 (GMT)

Can you think of any situation where implementation code would use the _fp prefix in a context where it's not reserved? Either way, what you suggest seems sensible. --Netocrat 00:54, 21 March 2006 (UTC)

Why not _just_ use the double underscore - and we could add a header [with an example version at the article] where the implementation-specific stuff is defined. --Random832 02:40, 21 March 2006 (UTC)

It's possible that implementation-reserved identifiers within example non-portable implementation code would also be needed, and it would be good to differentiate those from the identifiers that quarantine that code in the first place. On the rest of your suggestion: a comprehensive one-page listing of non-portability has value, but so does collecting all of the specific identifiers for each file/function into a per-page header - so let's do both. We could list those headers and their contents at Non-Portable Standard Implementation Components. We could use a convention to name those headers by prefixing "np_". Also, it would be good to avoid redundancy - let's define and explain np-identifiers in the article only when the identifier's used once-only (this may turn out to be the case for __np_anyptrlt), otherwise the def./expl. should occur on the Non-Portable Standard Implementation Components (but in either case it let's list it there). --Netocrat 22:50, 21 March 2006 (UTC)