Jump to: navigation, search

1 Introduction and topicality

It's a good idea to read at least the posting and topicality guidelines through before posting to comp.lang.c - lack of understanding carries risk of public embarrassment or confrontation. The group's FAQ is a separate, technical document.

1.1 What is comp.lang.c and how is it accessed?

comp.lang.c is a newsgroup within Usenet aka Netnews, and is traditionally accessed through a type of dedicated software known as a newsreader. Originally its name was net.lang.c. These days it's also accessible through various web interfaces such as Google Groups, some of which don't make it very clear that they're acting as a gateway to Usenet. If you're new to Usenet, the news.announce.newusers newsgroup and its links page are good sources of information.

1.2 How are newcomers welcomed?

Welcome to comp.lang.c!, originally penned and maintained by Billy Chambless with input from many regulars, is the generally accepted introductory post. Another answer to this question is, "it depends".

1.3 What's topical in comp.lang.c?

The group deals with C only to the (narrow) extent that the ANSI/ISO C Standard defines it. Several variants, including C89/90, C99 and "K&R C" are discussed, but most posting seems to center on C89/90 and/or how it differs with C99. The group's focus is on how to write portable C code; its sister-group comp.std.c deals with the Standard as a document, including how to interpret it.

The Standard covers C's syntax and its standard library. The standard library consists roughly of memory allocation, maths, file-based input/output, string-handling (including for extended multi-byte and wide characters), error-handling, date/time and general utilities - for such things as searching, sorting, pseudo-random numbers and numeric conversions.

There are many things that the Standard does not cover - in particular networking, graphics and filesystem directory functions - see also the next question.

Of course the definitive way to find out whether something is covered by the Standard is to read it; questions regarding whether something is or is not a part of the Standard are considered to be topical though.

1.4 What's not topical in comp.lang.c?

(proper netiquette suggests that before posting to any of the newsgroups listed below, you read the group's charter and FAQ, if any. FAQs are available from www.faqs.org and other sources. If those fail to answer your question then you should browse through at least two weeks of recent articles to make sure that your question has not already been answered)

  • OS-specific questions, such as how to clear the screen, access windowing or graphical interfaces, access the network, list the files in a directory, or read "piped" output from a subprocess. These questions should be directed to OS-specific newsgroups, such as comp.os.ms-windows.programmer.misc, comp.os.ms-windows.programmer.win32, comp.unix.programmer (general Unix: processes, pipes, POSIX, curses, sockets), comp.os.linux.development.apps, comp.os.msdos.programmer (DOS, BIOS, memory models, interrupts, screen handling, hardware), comp.os.os2.programmer.misc, comp.sys.mac.programmer.misc, comp.unix.[vendor].
  • Compiler-specific questions, such as installation issues and locations of header files. Ask about these in compiler-specific newsgroups, such as gnu.gcc.help, comp.os.msdos.djgpp (x86 version of the free gcc C compiler), comp.compilers.lcc (the LCC family of C compilers including LCC-Win32).
  • Writing a compiler. Ask about doing that in comp.compilers (compiler construction and theory, moderated).
  • Processor-specific questions, such as questions about assembly and machine code. x86 questions are appropriate in comp.lang.asm.x86, embedded system processor questions may be appropriate in comp.arch.embedded.
  • ABI-specific questions, such as how to interface assembly code to C. These questions are both processor- and OS-specific and should typically be asked in OS-specific newsgroups.
  • Algorithms, except questions about C implementations of algorithms. "How do I implement algorithm X in C?" is not a question about a C implementation of an algorithm, it is a request for source code. Appropriate newsgroups may be: comp.programming, comp.theory, comp.graphics.algorithms.
  • The C Standard, as opposed to standard C. Questions about the C standard are best asked in comp.std.c.
  • C++. Please do not post or cross-post questions about C++ to comp.lang.c. Ask C++ questions in C++ newsgroups, such as comp.lang.c++, comp.lang.c++.moderated.
  • Making C interoperate with other languages. C has no facilities for such interoperation. These questions should be directed to system- or compiler-specific newsgroups. C++ has features for interoperating with C, so for such questions consider comp.lang.c++.
  • Test posts. Please test in a newsgroup meant for testing, such as misc.test, alt.test.

[the above answer is based heavily on Ben Pfaff's comp.lang.c topicality guidance page with hints from Billy Chambless's Welcome to comp.lang.c! post]

1.5 Who decides topicality and posting guidelines for comp.lang.c?

The group's topicality isn't defined by a charter: its formation predates that system. Instead, topicality, posting etiquette and norms are defined and advocated by regular posters to the group, according to a long (internet time) tradition.

1.6 Why is comp.lang.c's topicality defined as it is?

Here's one regular's perspective: 

Literally
some of the most knowledgeable experts on C and C++ in the world help
others on comp.lang.c and comp.lang.c++.  That includes, not
infrequently, members of the language standards committees.  There is
plenty of historical evidence that these are the first to leave when a
group gets polluted by too much off-topic material. 

These groups are far too valuable as resources to be spoiled.  For
every poster who whines that "you can't write a real world program in
standard C (or C++)", there are many more who realize that you can't
write any program at all in C or C++ without using standard C or C++,
and usually far more than you use any extensions or third party
library.

And as for what the group "should" be about, that's spelled out by the
name:  "comp.lang.c" is nothing but an abbreviation for "computer
language C".  And there is one and only one internationally recognized
definition of the C programming language, the ANSI/ISO/IEC standard.

(Quoted from a post of Jack Klein's to comp.lang.c on 21 November 2005)

This wiki's C community:comp.lang.c:Portability attitude article - originally penned by Steve Summit - also explains, in some detail, why such importance is ascribed to portable C and why most regulars support the current topicality norms.

Occasionally posters assert that comp.lang.c's topicality norms should be changed. The changes each poster proposes vary in extent but a typical claim is that the group should allow discussion of common compiler extensions and of "real world" C. Often such posters appear to be motivated by dissatisfaction with the number of posts pointing out off-topicality, and they present an argument that there would be no need for such posts if broader discussion were allowed. Most posters advocating change do not adequately respond to the rationale outlined above and in the referenced article, and unless someone is successfully able to do so using effective reasoning, the norms are unlikely to change - at least whilst the current group of regulars hold sway.

Posters who typically provide assistance, or who typically participate in discussions amongst equals, arguably have more justification in challenging norms than assistance-seekers and new posters; it's uncommon for posters of that type to express dissatisfaction with current norms though. It could be argued that this is because those who might have expressed it don't stick around for long enough to do so, but those who do stick around seem to find the norms sensible - and most of them have demonstrated ample rationality through their programming endeavours and posts.

1.7 Why should I adhere to the norms described on this page?

Aside from the procedural benefits of the posting style described here, it's worth remembering that regulars aren't paid for their replies and their knowledge, so it's in the best interests of an assistance-seeker to adhere to topicality norms, posting guidelines, or anything else that regulars have come to a consensus on; it's also polite. Whether this page accurately reflects consensus is something readers will need to judge for themselves, but that's the aim of the page.

1.8 When should I post to comp.lang.c.moderated or comp.std.c instead?

  • comp.lang.c.moderated has the same purpose as comp.lang.c, but being moderated it has a slower turnaround and higher signal-to-noise ratio. It has a short FAQ. Don't post to comp.lang.c.moderated if you have time constraints - there's no other reason to choose either group except personal preference but crossposting to both is rarely useful.
  • comp.std.c is for "discussion about C language standards". Most discussion relates to the ANSI/ISO C Standard, including new proposals and interpretation of the Standard's wording and intent. Interpretation is an area of overlap between comp.lang.c and comp.std.c; discussion in comp.std.c is best saved for genuine ambiguity in the Standard's wording that hasn't already been covered (check the archives).

2 Posting to comp.lang.c

2.1 What should I do before posting a question?

Lurk for at least a couple of weeks or review at least a couple of weeks worth of posts to get an understanding of the group's posting norms and to check that your question has not recently been asked and answered.

Read How To Ask Questions The Smart Way by Eric Steven Raymond and Rick Moen.

Then as a rough checklist, verify that:

  • your question is topical (see the previous section)
  • your question is not answered in the FAQ or a basic C textbook, and if it's homework, that you're following the guidelines below
  • the subject line of your post is brief, descriptive and relevant ("Problem with enum and struct" is useful, "Urgent!! please respond" is not)
  • you've included the smallest, complete and compilable program that exhibits your problem
  • you've clearly and concisely stated your question or problem, describing both what you're trying to achieve and what problem you're running into
  • you've included all relevant output and error messages
  • you're using normal English grammar and capitalisation rules, and that your post is generally readable.

2.2 How should I ask homework questions?

Most posters to comp.lang.c will not provide ready-made solutions to obvious homework questions, but are generally willing to provide advice and guidance if you have at least attempted to answer the question yourself. Here's an annotated reference post: 

Ok so I have this class for C. I have to write this program for my
instructor,

1. Clearly state that your question is homework. Pretending that it's not doesn't work in comp.lang.c. You are also likely to get answers that, if you use them, will make it obvious that you did not do the work yourself. 

where he has already posted the softcopy and algorithm. But
my question is I have to convert meters to feet and in this I have to
output not only the feet but also the inches

2. Clearly state the problem to be solved. People in comp.lang.c are not mind readers. If you can't take the time to properly explain the problem then no one will take the time to answer. 

now I think I have coded
the feet calculation properly but. I don't know how to send the
remainder to inches and than recalculate it and display that
calculation

3. Clearly state what you are having a problem with. "It doesn't work" or similar indicates that you're lazy and haven't analysed the problem. Other people won't either. 

here is what I have coded this so far.

#include <stdio.h>
#define FACTOR 2.54
int main (void)
...

4. Post your attempt at solving the problem. No one's going to write code for you but if you have a go they will point you in the right direction and suggest improvements or point out the obvious errors. Make sure that it compiles too - if it doesn't, include a copy of the compiler diagnostics (the code in this post didn't compile and the poster failed to mention that). 

and here is the page with my instructors algorithm
http://www.[anonymised]/[anonymised].html

5. Include any additional information. If people don't have access to the same information that you have on the problem then they may give you the correct answer to a different problem. 

sorry i cant explain this better i am just lost right now

6. Be polite. You are asking for help....

Homework questions following this model are likely to attract serious and sensible help. The only lack to this post apart from compilable code is adequate punctuation; you're likely to be cut some slack in that area (as well as for poor spelling or grammar) if English isn't your native language, as was likely the case for this poster.

[the above answer was adapted from Chris Hills' post of 19 September 2005, how to ask for help with homework questions]

2.3 What should I avoid when posting?

  • Excessive capitalisation (the internet equivalent of shouting) or lack of capitalisation where it's usual, such as at the beginning of sentences.
  • Abbreviations like "u" for "you" or "pls" for "please", because it can be harder for readers not accustomed to them to parse them, especially for non-native speakers, and because most regulars of comp.lang.c by virtue of their appreciation for correct C (a programming language) also appreciate correct English (a human language).
  • Asking for an email response. Some people consider it rude to be asked to respond by email, because it deprives the group of the benefit of the response and because expecting people to take the time to answer a question without being willing to take the time to monitor for a response indicates a lack of respect. Some people consider it acceptable if you offer to summarise email responses in a later newsgroup post and if you follow through on that offer.
  • Placing a response above any quoted material to which you're responding. This is known as top posting and is particularly disfavoured in comp.lang.c - see also the how to quote answer on this page.

2.4 Should I start a new thread or reply to a post in an existing thread?

You should start a new thread for a new question unless you have a question that follows directly from something that someone else has written.

2.5 What should I do after posting?

Monitor for responses over a period of a week or so. Don't repost the message - it's possible that your original post won't appear until several hours have passed due to the nature of Usenet, and responses may take a few days to arrive. Reposted messages serve no purpose except to irritate your readers.

Participate in the resulting discussion to acknowledge advice that helped or solved your problem and to ask for further clarification when you don't understand the answer. It's not necessary to post individual thank yous to each reply, but it's polite to post at least one reply indicating whether you found what you were looking for and which solution you ended up using if several were presented. If you receive email replies, it's also considered polite to post a summary of them.

2.6 What sort of attention to detail can I expect?

Accuracy and attention to detail are highly valued in comp.lang.c, and errors other than those an original poster is asking about are likely to be critiqued in code too. Those not accustomed to this level of review may find it harsh or offensive, however corrections are usually not meant to be personal attacks, and are usually offered for the benefit of all readers, not just the original poster.

2.7 What general ettiquete guidelines apply?

Conventional netiquette applies, mostly based on the notion that the same respect should be applied to others online as in face to face conversation, with online-specific guidelines such as how and when to crosspost. For details see:

2.8 What should I do before posting a reply?

As for posting questions, lurk or review for a couple of weeks before posting.

If the post you're responding to is off-topic or is answered by the FAQ, convention is to point the poster to a more suitable newsgroup/resource or the FAQ, respectively.

If you're posting code as part of a solution, it's a good idea to test it first - at least that it compiles - and to indicate if you've not done that e.g. "The following code is off the top of my head and untested".

If you're answering a Standard-related question, it's a good idea to verify that your understanding matches the actual wording of the Standard before posting.

Realise that any errors that you make will probably be critiqued, possibly more harshly than you'd like, so be careful.

2.8.1 How and what should I quote, and why?

Quote sufficient context and no more. Intersperse your response with the quoted post, placing your comments immediately below the quoted material that you're responding to. Use the > (greater-than) character at the start of each quoted line. Use appropriate attribution lines to indicate who wrote what. Don't quote signatures. This may all seem very prescriptive, but the style has evolved for good reasons and it works well for such a high-traffic technical group.

For details see:

2.8.2 What should a Google Groups poster in particular be aware of?

Mostly that the default quoting style promoted by the interface is not appropriate for posting to comp.lang.c. The problem and solution are explained on Chris F.A. Johnson's Ga-Ga Google Groups and Netiquette page and in Safalra (Stephen Morley)'s Replying In Google Groups.

3 Reading comp.lang.c

3.1 What are good reasons to read comp.lang.c?

  • to learn how to write portable C code - portable in the sense that it's guaranteed to run correctly on any Standard-conforming implementation
  • to learn what is and what isn't portable C, and why
  • to pick up portable C tricks and tips
  • to learn and practice effective reasoning, written communication and debating skills.

3.2 What do the commonly used acronyms mean?

  • OP stands for "Original Poster"
  • OT stands for "Off-Topic".
  • UB stands for "Undefined behaviour".
  • C&V stands for "Chapter and Verse" and indicates that the writer wants a direct pointer to the relevant section of the Standard.

The meanings of various other acronyms can be discovered through The Jargon File, Urban Dictionary, a general web search or by installing the wtf program.

4 Resources

4.1 What does the FAQ cover?

The C FAQ is maintained by Steve Summit and is commonly referred to by regulars. The FAQ contains diverse material, from arrays and pointers to the preprocessor to style, and is suitable for programmers of all levels of ability. It's technical and can be read in isolation from the comp.lang.c newsgroup, so posting conventions aren't described there, but checking for an answer in the FAQ prior to posting a question is essential - it's a waste of time and bandwidth to post something addressed by the FAQ unless you can't understand it or genuinely believe it's incorrect.

4.2 Where can I find out about or obtain the Standard?

Refer to The C Standard#Obtaining_the_Standard. Access to at least a draft version of the Standard is useful for those intending to participate significantly in comp.lang.c.

4.3 Where can I get a compiler or IDE?

Refer to C resources:IDEs and C resources:Compilers.

5 Off-topic pointers, pedantry and friendliness

5.1 Why do so many responses point out that a post is off-topic?

Many (new or posing-as-new) posters don't follow the norms of the group. The reason is probably one or more of:

  • ignorance that norms exist
  • a deliberate attempt to annoy some readers or posters
  • a deliberate (implicit or explicit) assertion that the norms are illegitimate or should be changed.

It's certain that at least some of the posts are deliberate attempts to annoy (troll posts). It's also certain that many newcomers (particularly from Google groups) often simply aren't aware of the group's norms or Usenet basis and are willing to adapt when the norms are diplomatically pointed out.

Given that it bears results, some of the regulars elect to perform this pointing out. When performed insensitively the task carries the risk of an angry or indignant response, or being labelled a "netcop" (pejorative), as well as being in itself irritating in its repetitiousness. For this reason most posters providing such meta-topical advice where possible provide topical advice at the same time, and/or suggest a newsgroup or other forum where the poster's question might be more topical.

5.1.1 Aren't these posts themselves off-topic?

No - by general Usenet consensus, discussion of a group's topicality is in itself topical.

Aside from this such posts could be considered topical in that they inform new readers as to what is and what isn't part of the C Standard.

5.2 What's the role and effect of pedantry in comp.lang.c?

As a focussed technical newsgroup, comp.lang.c partly depends on an approach near enough to pedantic that the group's etiquette allows for pedantry. C is governed by an international Standard that leaves much undefined and that requires careful interpretation. Without pedantic responses many subtle errors and intricacies would not be pointed out to readers. "Pedantic" is probably also one part of the description of the thought processes required for or acquired whilst programming and debugging C code.

The pedantic label is often acknowledged tongue-in-cheek by regulars. This attitude provides a clue that even in comp.lang.c pedantry is not universally respected. In some forums pedantry would be considered disrespectful or rude in general. There are occasions in comp.lang.c where the same etiquette applies. Someone who puts a lot of thought and effort into a post or who is making an important point or one based on hard-won personal experience, is likely to find a glib or boilerplate reply offensive - and with good justification, especially if the reply is unresponsive or irrelevant to the original post's message.

For this reason: be cautious with pedantic responses. Make sure that there's really a need to clarify or correct a detail. Try to acknowledge the main point(s) of the original post even if you have nothing in particular to add to it.

There's one case where the above guidelines apply less strictly, although some posters follow them anyway: new posters whose complete ignorance of comp.lang.c norms demonstrates that they haven't been courteous enough to learn about the locals before jumping in. Often the objections of these posters to pedantic replies are met with "grow a thicker skin", which if not an advisable response is at least an understandable one.

An arguably negative effect of comp.lang.c's pedantry is debates that are unrelated to the C language and important to only a few participants.

5.3 Is comp.lang.c a friendly group?

Some argue that pedantry and repetitive instruction of group norms combine to encourage a surly, unfriendly and overly combative environment where many posters' real questions, by being deemed off-topic, aren't answered and the emphasis is on being right at all costs. There have been campaigns for a friendlier comp.lang.c in the past.

The genuine expertise that resides in the group is probably one mitigating factor for those who consider aspects of comp.lang.c unfriendly yet who continue to follow it. Another spin on this is that comp.lang.c is actually an extremely friendly newsgroup, but it's fussy about its friends. If you are a thoughtful, considerate person with a genuine desire to learn the C language, you will find comp.lang.c a very friendly place after all.

Shortcut links for Usenet posting

The page Introduction to comp.lang.c redirects here, so a convenient short url for posting to Usenet is: http://clc-wiki.net/wiki/intro_to_clc (the "i" in intro can optionally be capitalised).

Also, the number preceding each question hyperlinks to a briefer direct url than provided by MediaWiki by default when clicking on the question in the table of contents.

Retrieved from "https://clc-wiki.net/mediawiki/index.php?title=C_community:comp.lang.c:Introduction&oldid=7371"
Personal tools