Is it time for comp.lang.c.dos?

[Loyde W. Hales II]

In article <23648 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>>``I'm having a problem with malloc() in Utah.''  The problem has
>>nothing to do with Utah (I hope), but where is the defect?  Is it my
>>understanding of malloc, my understanding of C, my Zortech C compiler,
>>my copy of GNU malloc, my Amiga computer, my homebrew operating
>>system, my extended memory board, or my neighbor's cat?

>In this case, a reasonable approach would be to pick the thing you think
>is the most likely source of error.  For instance, if you think the problem
>is in the C implementation, post to a newsgroup dealing (as exclusively
>as possible) with that implementation.  If you think the problem is
>most likely in the GNU malloc, post to gnu.<whatever>.  If you think
>the problem is most likely in your understanding of malloc, post to
>comp.lang.c.  In any case, (a) state the problem; (b) give the details
>that are relevant to the newsgroup/problem-solving-group; (c) try to
>phrase the question such that it is relevant to the group.

>In other words, the comp.lang.c posting might say:

> ``I am not sure I am using malloc correctly.  Here is the idea; here is
>   the code.  Is this correct?  Please answer via electronic mail.''

>while the comp.sys.amiga.tech posting might say:

> ``I tried the code below.  It fails; I think it might be because there is
>   a glitch in the extended memory hardware.  If this is the case, how can
>   I fix it?''

>and so on.  (Of course, you could post one article, cross-posted, with
>sections relevant to each newsgroup.)

To a point, I agree.  There are, however, problems with the ``post only to
the most likely newsgroup, then with only correct questions'' approach.

1. Who is to say which newsgroup is correct?
   No, I am not trying to be facetious.  I've seen too many times when a
   question flamed on comp.lang.c was reposted to a different newsgroup,
   just to be flamed there.

2. Is it logical to expect someone with a problem to _know_ the cause?
   Sure, in some cases it is.  There have been times, though, where I've
   had no idea if my problem was with Xlib, Xaw, Xmu, Xt, Sun, Unix, or the
   neighbor's cat.  (She's really pretty, easily takes my attention. :-)

3. Should ``rules'' prevent quicker response?
   Anyone out there in business? :-)  Then you know the problems with meeting
   deadlines.  I'm not going to flame someone for wanting the quickest answer
   possible, and posting to 1+ newsgroups to get it.

4. Is there a ``most appropriate'' newsgroup?
   Answer here is frequently ``no,'' particularly when limited-use local
   sites are considered.  My site is rather large, and we don't carry a
   newsgroup for every possible computer and compiler.

5. Do you have the right to restrict discussion?
   At a point, of course, the answer has to be ``yes.''  This is a matter of
   finding the point.  I, among others, like the varried discussion carried
   on this newsgroup.  I don't want to try to read 500 different newsgroups
   where most messages don't deal with C.  I won't die if they disappear, but
   I question why you should complain that they are here.

6. You can always use the KILL file.
   Every news program I've seen (save one) has a search-and-kill option.  If
   your major problem is with articles you feel deal with hardware-dependent
   issues, just junk the things.  It isn't that hard to search for them.

There are other arguments, but I don't want to cost the Net an additional
$1000 to make them.  I think the point gets across.

Oh, and for the record, I have never posted an article to this newsgroup not
dealing strictly with C, save for the arguments over whether it is valid to
post said articles.

-=-

                                Department of Computer and Information Science
Loyde W. Hales, II                      The Ohio State University
lwh at cis.ohio-state.edu          2036 Neil Avenue Mall, Columbus, Ohio  43201