Should we broaden the topicality of this group?

[Philip Potter]

One of the (several) bugbears that haunts this group is the issue of
topicality. There appear to be several topicality camps within clc at the
moment, which I'll attempt to categorise as neutrally as I can manage.
I'll assign a name and a letter to each group in an attempt to make it
easier for us all to discuss the various camps.

Group P (Purists): only code that can be written entirely in K&R C, C90, or

Group N (Neopurists): only code that can be written entirely in the latest
version of C

Group C (Conservatives): whilst the principal focus should be on standard
C, discussions of particular implementations and extensions for
illustrative purposes are acceptable.

Group M (Moderates): As well as standard C, common extensions should be
considered topical (e.g. those that are common in Windows (GUI and
console) and in Unix-a-likes).

Group X (eXperimentalists): These folks would like discussions of possible
changes and enhancements to the language to be considered topical.

Group L (Liberals): Anything written in a vaguely C-like syntax or in a
language based on C is topical (including C++, Objective-C, Java, and C#).

Group A (Anarchists): Anything and everything is topical, including device
drivers, Shrek, CD marker pens, jokes about viola players, and the
Metropolitan District of South Humberside.

I don't feel that the topic is a problem, but how it is policed is.

Topicality breaches should not be clamped down on every single time, and
that topicality policing should both be friendly and explain properly to
the poster /why/ their post is offtopic and /where/ they can get the
info they seek.

On top of that, I think that simply mentioning an
implementation-specific feature or using it within a posted program
shouldn't be a crime, especially if it's obvious to that the problem is
a standard C problem. For example, consider the following program:

#include <conio.h>
#include <stdio.h>
int main(void) {
char *name = "David";
gotoxy(10,20);
printf("Hello, %c!\n",name);
return 0;
}

While it is not standard C, because it uses <conio.h> and gotoxy(), I
feel that the ideal response to this would be to politely explain that
implementation-specific features are offtopic but to point out the
problem anyway, because the problem here is in standard C code[1]. I do
/not/ think that redirection would be appropriate.

I think that topicality violators are often treated with a short temper
here, because the regulators are tired of such violations. However
because there are so many different people asking questions, it might be
their first time posting here and so simply shouting "Offtopic!" at them
will leave them bewildered and frustrated.

I also think it is childish that some posters will immediately jump on
anyone mentioning C++ or (horrors!) "C/C++". Questions about C++ are
offtopic. But simply mentioning these things is not. This problem is
even mentioned in the clc++ FAQ, question 5.4:

'Do not refer to "C/C++." Some people get testy about that, and will
(unfortunately!) ignore everything else you say just to correct you with
something like, "There is no such language." It borders on pathetic, but
you'll probably be okay if you say "C or C++" instead of "C/C++." Sigh.'

In short, while I would put myself into the C group above, I feel that
minor topicality infractions should be tolerated, and blatant ones
treated with patience.

[1] Unless gotoxy() never returns. In which case you can add this
condition to your reply.

 

[Chris Hills]

I don't feel that the topic is a problem, but how it is policed is.

Topicality breaches should not be clamped down on every single time,

I agree absolutely. All it does is generate a lot of noise about
topicality.

and that topicality policing should both be friendly and explain
properly to the poster /why/ their post is offtopic and /where/ they
can get the info they seek.

The problem is there is a SMALL group of Net Nannies who have an
artificially small definition of topicality that is at odds with a large
number of us...

It is at odds with a large number of people simply on observation of the
number of times they scream Off Topic!

On top of that, I think that simply mentioning an
implementation-specific feature or using it within a posted program
shouldn't be a crime,

Absolutely. The Vast majority of people are programming in an
environment that is not pure ISO C

While it is not standard C, because it uses <conio.h> and gotoxy(), I
feel that the ideal response to this would be to politely explain that
implementation-specific features are offtopic

This is where we disagree. The Implementation specific stuff is NOT Off
Topic.

Actually parts of ISO C would be OFF Topic as no one has implemented
them and are not actually used in reality

but to point out the problem anyway, because the problem here is in
standard C code[1]. I do /not/ think that redirection would be
appropriate.

I agree here. Look at the bigger picture not the pedantry. That is what
annoys many of us.

I think that topicality violators are often treated with a short temper here,
Yes.

because the regulators are tired of such violations.

No, they are pedants with an artificially narrow view of what this NG is
about that annoys the majority.

However because there are so many different people asking questions,

Precisely they majority have a different view of what is On topic than
the Net Nannies

it might be their first time posting here and so simply shouting
"Offtopic!" at them will leave them bewildered and frustrated.

Yes... And gets this NG a bad name.

I also think it is childish that some posters will immediately jump on
anyone mentioning C++ or (horrors!) "C/C++". Questions about C++ are
offtopic. But simply mentioning these things is not. This problem is
even mentioned in the clc++ FAQ, question 5.4:

I agree absolutely however It is important to mention that "C/C++" is
not a language and the two are separate. That is important. They
behave differently.

'Do not refer to "C/C++." Some people get testy about that, and will
(unfortunately!) ignore everything else you say just to correct you
with something like, "There is no such language." It borders on
pathetic, but you'll probably be okay if you say "C or C++" instead of
"C/C++." Sigh.'

I think that you do have to explain that C ++ came off C90 and that C
and C++ have diverged since.

The problem I have is when the question is cross posted to the C and C++
NG's the Net Nannies will (often silently) stop the cross posting so
that people reading it in the C NG will not realise they are missing
half the discussion. Usually the less pedantic and more useful half.

In short, while I would put myself into the C group above, I feel that
minor topicality infractions should be tolerated, and blatant ones
treated with patience.

I agree. A bit of toleration and stopping all the OT posts (and their
counters) will cut the noise to signal ratio a LOT and will improve this
NG's reputation in the world.

 

[Malcolm McLean]

Meta (from Greek: [...] = "after", "beyond", "with"), is a prefix
used in English in order to indicate a concept which is an abstraction
from another concept, used to complete or add to the latter. The Greek
meta is equivalent to the Latin post.

The original "meta-" word of this kind is metaphysics, which was the
name given to one of Aristotle's works. In that case, the meaning is
said to be "after", in that the work was taught after Aristotle's
"Physics".

The relation between the subject matter of Aristotle's Physics and
Metaphysics ("natural philosophy" and "ontological philosophy") has
probably influenced the use of the prefix in English as much as
meaning of the Greek prefix itself has.

Orinally it was purely a librarians' term, referring to the shelving of the
two volumes.
Now it means "applied to itself". You often need a meta-discussion about say
the medium of communication, or rules for functioning of the group. Or you
might want to do a meta-study about how scientists come to their
conclusions, or write a meta-language for describing other programming
languages.

"Metaphysics" is now an exception. It doesn't mean "physical things applied
to other physical things", but "what arises from the physical world but is
not of it".

 

[Keith Thompson]

Yes but.... This NG should act as a place where C can be
discussed. With the current Net Nannies you cant, as some one said ask
about spawn because it is not standard. The others that did
constructively discuss the topic with the OP said you really need
something like "system()" SO after a little more cross platform
discussion he was then pointed in to an NG for specific in depth
discussion. Which wasn't a Unix one where he might have been sent for
"spawn" thus everyone learns and more importantly people get more of
an idea about what is and is not portable to their system. This is
important as very few use just pure ISO C.

[...]

Why would the OP have been sent to a Unix group to ask about "spawn"?
That's not a Unix function.

I don't remember the specific discussion, but IMHO a reasonable
response to someone asking about "spawn" would have been something
like:

The "spawn" function is not part of standard C. You'll get better
information if you ask in a newsgroup that discusses whatever
operating system you're using. The standard C function "system"
*might* server your purposes, but it's hard to tell without more
information about what you're trying to do.

If the OP asked something like "How do I use spawn", I might also
suggest that a better question would be "How do I do foo", where the
OP needs to replace "foo" with whatever goal he's trying to achieve
rather than assuming a specific solution.

And ideally, if the OP really did need information about "spawn", that
would be the end of it as far as comp.lang.c is concerned. Of course,
due to the asynchronous nature of Usenet, there will inevitably be
multiple replies saying more or less the same thing -- and perhaps one
or two trying to explain how to use "spawn" (with subtle errors)
without bothering to mention that it's not portable.

I'd try to provide a more specific redirection if I knew what system
provides "spawn" (I honestly don't), but surely the OP knows what
system he's using, and can find a more appropriate newsgroup or other
forum himself.

 

[Keith Thompson]

I have seen far too much of this pedantry and one upmanship....
People pedantry quoting chapter and verse in DRAFT UN-ISSUED
documents (because it is "close enough") but ignoring common real
world use of the language

I generally quote from n1256.pdf. This is not just a draft un-issued
document; it consists of the C99 standard as amended by TC1, TC2, and
TC3, all four of which are official documents issued by the ISO C
committee. I could construct a citation by using the official C99
standard and carefully cross-referencing the section number against
TC1, TC2, and TC3 (I have copies of all four documents), but it would
take several time as long, and I expect that the result would be
exactly the same -- except that it would introduce more opportunities
for error than just citing n1256. I trust the editors who produced
n1256 to have gotten it right; I see no point in re-doing their work.
In a critical context (say, where a contract requires strict standard
conformance), I'd go to the trouble of checking the actual standard
and the TCs (even if the TCs are excluded, I'd want to know about any
changes) -- but a Usenet post is not nearly that critical.

In cases where n1256 differs from C99, I mention it.

Do you *really* maintain that n1256 isn't good enough for citations in
the casual discussion that is comp.lang.c?

I know of exactly one person who commonly quotes from a pre-C99 draft,
n869, and I've complained about that myself.

[...]

The problem was the more useful part of the discussion on c and C++
was on the C++ group as it had silently disappeared from the C NG.
Many on the C group would not have seen this due to the unilateral
censorship by the Net Nannies.

I object to your use of the word "censorship". I am not able to
censor this newsgroup, and I wouldn't even if I could. Asking someone
to post something elsewhere is not censorship. If you're able to say
anything you like, you're not being censored.

And perhaps you could avoid the use of the term "Net Nannies", at
least in this thread. Richard H. tried to start, and I'm trying to
continue, a reasonable discussion; name-calling is not helpful.

 

[Keith Thompson]

I agree. A bit of toleration and stopping all the OT posts (and their
counters) will cut the noise to signal ratio a LOT and will improve
this NG's reputation in the world.

I disagree. If nobody ever points out that some posts are off-topic,
this newsgroup will most likely become known as a place where you can
ask about anything with "C" in its name. (That may be an
exaggeration, but it's not much of one.)

I for one don't want this newsgroup to discuss POSIX-specific
functionality, or Windows-specific functionality, or C++ or C# or
Objective-C. There are *already* newsgroups for those things.
comp.lang.c is the *only* newsgroup for discussion of standard C; I
don't want to lose that.

I'll grant you that some of us are sometimes a bit too abrupt in
pointing out that something should be discussed elsewhere. Pretending
that some system-specific function doesn't exist is less than
constructive; if I happen to recognize the name "fork", for example,
I'll suggest posting to comp.unix.programmer rather than asking to see
the source code for "fork" in portable standard C. Insults are
inappropriate, except perhaps in the most blatant cases of abuse.

In my opinion, the trolls are a much bigger problem than the so-called
Net Nannies. There are several posters here whose only purpose in
life seems to be to complain, and who rarely if ever make any
technical contribution. (I certainly don't count you in that group,
Chris.)

 

[Default User]

Philip Potter wrote:

Topicality breaches should not be clamped down on every single time,

If it's not, then it gives the appearance of inconsistency or
arbitrariness.

and that topicality policing should both be friendly and explain
properly to the poster why their post is offtopic and where they can
get the info they seek.

By and large, it is polite. I'll admit I don't like "What is your C
language question?" I've also complained in the past about the "willful
misaprehension" that some people use. Redirections should not be viewed
as an opportunity for comedy routines.

However, I find that such problems are relatively few. Most of the
redirections are professionally and politely done.

On top of that, I think that simply mentioning an
implementation-specific feature or using it within a posted program
shouldn't be a crime, especially if it's obvious to that the problem
is a standard C problem. For example, consider the following program:

Most of the time, the off-topic elements are pointed out and the real
problem diagnosed.




Brian

 

[Chris Torek]

Group P (Purists) ...
Group N (Neopurists) ...

Group C (Conservatives): whilst the principal focus should be on standard
C, discussions of particular implementations and extensions for
illustrative purposes are acceptable.

Group M (Moderates): As well as standard C, common extensions should be
considered topical (e.g. those that are common in Windows (GUI and
console) and in Unix-a-likes).

Group X (eXperimentalists) ...
Group L (Liberals) ...
Group A (Anarchists) ...

Given the above set, I would put myself in group C with perhaps
even a hint or shade of group M. Of course, I am not sure I
agree with the set of groups in the first place, but for survey
purposes, I think placing me in "group C" is most appropriate.

 

[Richard Heathfield]

Chris Torek said:

Given the above set, I would put myself in group C with perhaps
even a hint or shade of group M. Of course, I am not sure I
agree with the set of groups in the first place,

Neither am I, actually! But I wanted to give people /some/ kind of common
basis for discussing whether the topicality of the group should be
extended, and this seemed like a reasonable way to do that. If I'd spent a
few months thinking about the groupings, I could probably have done a far
better job.

 

[Philip Potter]

This is where we disagree. The Implementation specific stuff is NOT Off
Topic.

It most certainly is.

No, they are pedants with an artificially narrow view of what this NG is
about that annoys the majority.

I happen to assume the best in people.

I agree. A bit of toleration and stopping all the OT posts (and their
counters) will cut the noise to signal ratio a LOT and will improve this
NG's reputation in the world.

You'll never stop /all/ the OT posts. I doubt you'll even get close.

 

[Kenny McCormack]

(The CBF troll wrote)

Where did I write anything about recommending code? The statement you
were responding to was (as you can still read above):

I see nothing wrong in discussing the idiosyncracies of a specific
dialect.

Please do not feed the troll.

 

[Kenneth Brody]

I'll vote for C.

Firstly what irritates some people is not so much the fact of off-topic
redirections as the tone. Supercilious references to "your particular
platform" when the particular platform is Windows don't always help. The
reality is that for many people Windows is computing, and no one likes to be
made to feel inferior because he doesn't have a nice Unix box to play with.

While I can only speak with certainty about my own posts, I don't
believe that others posting with "your particular platform"
references are trying to make the other person "feel inferior",
regardless of what "particular platform" is being referred to.
Rather, the purpose is to point out that this group isn't about
_any_ particular platform. In fact, most such replies probably
have nothing to do with it not being a "nice Unix box", as I
doubt the answer will be Unix-specific. More likely, the answer
will be DS9K-specific, which fits right into group "C"'s use of
such things for illustrative purposes. ("While your particular
platform may include a function clrscr() to clear the screen, on
my DS9K it is used for Commence Launch (Remote Systems Console
Request)".)

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenneth Brody]

Richard Heathfield wrote:
[...]

Group C (Conservatives): whilst the principal focus should be on
standard C, discussions of particular implementations and extensions
for illustrative purposes are acceptable.

I'm not quite a purist (probably because I work in the POSIX world,
so "pure ISO C" isn't something I usually concern myself with), so
this one probably most closely fits my perceptions.

I also don't have a problem with code samples which refer to "non-
Standard" functions, as long as such functions are not the focus
of the discussion. (ie: a program which uses sockets, but which
is having a problem unrelated to the sockets, or a program which
calls "clrscr()" at the beginning, as long as the question isn't
"why doesn't this clear the screen".)

[...]

Group X (eXperimentalists): These folks would like discussions of
possible changes and enhancements to the language to be considered
topical.

Is such discussion topical for comp.std.c? (I freely admit that I
do not hang out there.) If not, then discussion about the pros and
cons of a new feature may be topical here. If it is topical there,
then it probably belongs there.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenneth Brody]

I would put my self here.


Yes but.... This NG should act as a place where C can be discussed. With
the current Net Nannies you cant, as some one said ask about spawn
because it is not standard.

Well, I agree that a discussion of spawn() is OT here in clc. The
fact that it is available on a "common" platform like *nix doesn't
really enter into it. It's not available on Windows, and I hate
to imagine what is does on the DS9K. Who gets to decide which
"common platforms" are topical and which arent? How "common"
must a platform be? Can every POSIX function be discussed?
Can we discuss using "raw mode" input on *nix, and getting the
status of the "Alt" key on Windows?

The others that did constructively discuss
the topic with the OP said you really need something like "system()"

And system() is on-topic here, AFAIK.

With something like spawn(), there are two "correct" paths that I
see. You can direct them to comp.unix.programming to discuss it
over there, or you can use your "outside of clc knowledge" to see
what the OP was trying to do, and direct them to a standard way of
accomplishing the task. Not every such discussion has a path to
topicality.

SO
after a little more cross platform discussion he was then pointed in to
an NG for specific in depth discussion. Which wasn't a Unix one where he
might have been sent for "spawn" thus everyone learns and more
importantly people get more of an idea about what is and is not portable
to their system. This is important as very few use just pure ISO C.
I hope so.....

I think he listed it because there are people who apparently fall
into that category, just as there are some who apparently fall into
group A.

[...][...]


--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[CBFalconer]

Where did I write anything about recommending code? The statement you
were responding to was (as you can still read above):

I see nothing wrong in discussing the idiosyncracies of a specific
dialect.

"idiosyncracies" are another word for "incorrect code", in that
such code will not compile and run correctly on any standard C
system. The point is that correctness is _always_ required. The
only available standard for such is the ISO standard(s).

If you really have a more restricted meaning in mind, such as
discussing how to rewrite something in 'idiosyncratic' code into
standard C, that is another matter.

 

[Al Balmer]

Precisely they majority have a different view of what is On topic than
the Net Nannies

Perhaps I owe you an apology. I seem to have missed both the poll
which established that your view is the majority one, and the election
of you as the spokesman for the majority.

BTW, calling names is generally an indication that you've used up any
rational argument you might have.

 

[Chris Hills]

"idiosyncracies" are another word for "incorrect code", in that
such code will not compile and run correctly on any standard C
system

There are no C compilers in the world. Non are fully C99 compliant and
have no extensions.

 

[CBFalconer]

There are no C compilers in the world. Non are fully C99 compliant
and have no extensions.

I find it quite possible to compile standard C code on a
non-compliant compiler. However, code that compiles on that
(faulty) compiler is not necessarily compilable elsewhere. You
seem to have great confusion between cause and effect.

BTW, "gcc -W Wall -ansi -pedantic" comes fairly close to C95
compliance, and I expect very few problems porting code so compiled
elsewhere.

 

[Chris Hills]

I find it quite possible to compile standard C code on a
non-compliant compiler. However, code that compiles on that
(faulty) compiler is not necessarily compilable elsewhere. You
seem to have great confusion between cause and effect.

The compiler is NOT faulty. If you insist on that sort of stupidity
there is not a non faulty C compiler on the planet.

Also a pure ISO C compiler is of little use to most people. They NEED
the extensions in order to do efficient programs on most targets.

I wonder how people can get compilers for use on 61508 SIL3, 60601-1-4
and Do187B projects if these compilers are "faulty"

You seem completely at odds with the safety critical world and I know
which one I would bet my life on... let alone my money.

This is my problem with the small group of net nannies on here. They are
out of touch with reality.

 

[Jean-Marc Bourguet]

One of the (several) bugbears that haunts this group is the issue of
topicality. There appear to be several topicality camps within clc at the
moment, which I'll attempt to categorise as neutrally as I can manage.

The title is already not neutral: some think that your groups P and N
(well, I don't identify anybody in this last group; well, I can see someone
playing as one as a way to show the absurdity of the position of Ps) are
trying to artificially restrict what is topical.

As I don't wan't to try to put myself under one of your label. I think
that this group should be about the C programming language as used in
practice while comp.std.c is for the theory.

In theory, theory and practice are the same, and so we need only one
newsgroup instead of two. In practice, they differ, so one has to accept
more: older standards, common extensions, things provided by some other
tools, relationship with other languages, common libraries (included OS
API).

Now, there is a problem. Where to put the limit? In what I've outlined
above, it seems to me that there are two potential source of abuse:
libraries and tools.

For sure, the configuration of the color of the cursor in the editor of
your IDE is out of topic. For sure, the interest of some non mandatory
warnings should be topical. And between the two there is a gray area for
which I'd have difficulty to define if I want it topical or not.

Likewise for the libraries. Pointing to gmp or similar libraries when
asked for arbitrary precision integer arithmetic is the thing to do.
Discussing XCrossingEvent should be done elsewhere.

I said there are gray areas that I'd have difficulty to classify. I'm
conscious of factor which increase the acceptability:
- there is no standard way of doing it
- the point is discussed while discussing other points more clearly topical
- the discussion has drifted
- the point is widely applicable (not in term of number of deployed
systems, more in term of number of C implementations).

Yours,