Should we broaden the topicality of this group?

[CBFalconer]

Chris Hills wrote: *** and eliminated attributions - bad ***

.... snip ...

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.

It certainly is faulty if it is failing to warn about deviations
from the ISO standard. Granted, this is more a QOI factor than a
fault.

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.

You keep failing to realize the topicality. There is adequate room
for discussion of those specialized compilers on
comp.arch.embedded. This is NOT comp.arch.embedded. This is
comp.lang.c, where topicality is defined by the various historical
C standards.

 

[Malcolm McLean]

I think we can all agree that both Tanmoy and Dan Pop had incredible
knowledge of the C language.

Where is Dan Pop? Anyone know what became of him?

 

[Malcolm McLean]

I want to be able to discuss C as it is used. Which is Not pure ISO C. If
you want to discus just pure ISO C go to comp.std.c

I write virtually all of my work programs in pure ISO C. The exception is
those which are parallelised, and call the MPI library. I've also got a
"Baby X" GUI project which isn't going anywhere very fast.

 

[Ben Pfaff]

There is a header file foo.h, which defines a macro like this:

#define MAGIC_CHARACTER 'x'

The main program #includes foo.h and does some stuff that depends on which
character is selected to be magic. The intent is that the user can change the
x in the header file and recompile to get a different result.

I would like to create a log file whose name contains the magic character. If
MAGIC_CHARACTER had been defined as a string ("x" instead of 'x') I could do
this:

logfp=fopen(MAGIC_CHARACTER ".log", "w");

char filename[] = {MAGIC_CHARACTER, '.', 'l', 'o', 'g', '\0'};

or

char filename[BIG_ENOUGH];
snprintf(filename, BIG_ENOUGH, "%c.log", MAGIC_CHARACTER);

or, in C99,

logfp = fopen((char[]) {MAGIC_CHARACTER, '.', 'l', 'o', 'g', '\0'}, "w");

None of these are ideal of course.

 

[Default User]

Keith Thompson wrote:

On the other hand, if the trolls would stop trolling, and if certain
non-trolls would stop complaining about attempts to encourage
topicality, I believe that the signal-to-noise would improve
dramatically.

I would (again) encourage people to stop engaging the people in those
groups in debate. I have to encourage myself too.






Brian

 

[CBFalconer]

The only place in this subthread where CBF used the word "faulty" was
the following:


It seems to me that he is saying that non-compliant compilers are
faulty. I see nothing wrong with this point of view. The context
suggested that he may have (mistakenly) considered a compiler with
extensions to be nonconforming, but I'm sure that he agrees with the
standard that compilers may implement extensions if they like.

Non-compliant does not exclude extensions. However syntax
extensions are automatically non-compliant, and require warnings.
Connection to other routines requires the source of such routines
to be portable, and those routines themselves need to be written
(or at least writable) in standard C. If the code is not portable,
it does not belong in c.l.c. The point is dual - the readership
cannot intelligently comment on undefined things, nor can they
comment on the usage of such beasts.

The parentheses around (faulty) were intended to imply a
possibility. Otherwise I would have simply omitted the
parentheses.

This seems to be a fairly silly discussion, since there is no
reason not to take the off-topic discussions to appropriate
newsgroups.

 

[Richard Harter]

And how exactly do you know that? The past history of comp.lang.c++
suggests that it most likely *would* decline into a chaotic mess,

What on Earth do you think comp.lang.c is now?



Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
But the rhetoric of holistic harmony can generate into a kind of
dotty, Prince Charles-style mysticism. -- Richard Dawkins

 

[Kenny McCormack]

superior to Dan Pop's. I think that we tend to navigate to the Dan
Pop "Slam the door in the newbie's face" school of graciousness simply
because it tends to be easier.

And a lot more fun. (cough, cough) CBF.

 

[Ian Collins]

I write virtually all of my work programs in pure ISO C. The exception
is those which are parallelised, and call the MPI library. I've also got
a "Baby X" GUI project which isn't going anywhere very fast.

You are probably part of the small minority of the small minority of C
programmers who know what pure ISO C is who use it...

Most C programmers these days will be doing embedded and DSP work, which
invariably makes heavy use of the extensions provided by the vendor for
the specific target. I'm not saying that most of the code for these
environments can't be written in standard C, with platform specifics
confined to separate modules (I do this and encourage others to do the
same), but that is simply isn't.

So I think that while encouraging standard C, a group such as this
should cater for all C programmers and not pounce on any non-standard
code like a pack of wolves. By all means point out a more correct way,
but don't let the corrections swamp the often simple answer to the
original question. All too often threads here degenerate into what is
and what isn't standard C long after the original question has been
answered.

How about we all try to answer the specific questions asked first, then
point out how to correct non-standard forms? I'm sure it wouldn't be
too hard to make c.l.c a more friendly place.

 

[user923005]

You are probably part of the small minority of the small minority of C
programmers who know what pure ISO C is who use it...

Most C programmers these days will be doing embedded and DSP work, which
invariably makes heavy use of the extensions provided by the vendor for
the specific target. I'm not saying that most of the code for these
environments can't be written in standard C, with platform specifics
confined to separate modules (I do this and encourage others to do the
same), but that is simply isn't.

So I think that while encouraging standard C, a group such as this
should cater for all C programmers and not pounce on any non-standard
code like a pack of wolves. By all means point out a more correct way,
but don't let the corrections swamp the often simple answer to the
original question. All too often threads here degenerate into what is
and what isn't standard C long after the original question has been
answered.

How about we all try to answer the specific questions asked first, then
point out how to correct non-standard forms? I'm sure it wouldn't be
too hard to make c.l.c a more friendly place.

I guess that redirection to a dsp group is better than answering the
question here. In such a case a polite redirection serves the OP
better than giving the answer here.

On the other hand, it may be that this group is the best place to
answer it. In that case it should be answered here. If the answer is
a single sentence or something innocuous like that, then the best
answer may be to answer the question directly along with redirection
to a better newsgroup. However lengthy answers about DSP specific
stuff are of no interest to me {for instance}. I suspect that you
would not be terribly interested in how to navigate an OpenVMS
directory structure. Someone else might object to Windows API calls.
Yet another person might not want to know about shared memory on
Linux. In short, I think that long discussions about things that are
*better* answered elsewhere are a disservice to the newsgroup and to
the OP.

 

[Mark McIntyre]

I can't overlook this ludicrous remark. As I've bothered to read up on
who some of the people Richard complains about are, I can say with
some comfort that most of them have more real world experience in
their little fingers than the rest of us can dream of.

(snip code)

I agree here too.

However given that this is a false situation, the question was
disingenuous at best.

The most likely answer in this case would be "how can we tell without
knowing what mstruct.h contains?"
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Ian Collins]

I guess that redirection to a dsp group is better than answering the
question here. In such a case a polite redirection serves the OP
better than giving the answer here.

On the other hand, it may be that this group is the best place to
answer it. In that case it should be answered here. If the answer is
a single sentence or something innocuous like that, then the best
answer may be to answer the question directly along with redirection
to a better newsgroup. However lengthy answers about DSP specific
stuff are of no interest to me {for instance}. I suspect that you
would not be terribly interested in how to navigate an OpenVMS
directory structure. Someone else might object to Windows API calls.
Yet another person might not want to know about shared memory on
Linux. In short, I think that long discussions about things that are
*better* answered elsewhere are a disservice to the newsgroup and to
the OP.

I should have expressed my view clearer, I didn't intend to say provide
a detailed answer to a completely platform specific question which would
be better answered elsewhere. I was referring to the common form of
question where there is an obvious C language problem, but the posted
code contains something non standard, say <conio.h> or <curses.h>. More
often than not, these are dismissed as off-topic by virtue of the
platform specific code when there is a simple platform neutral answer.

Sure if the question relates directly to the behavior of platform
specific libraries or tools politely send the poster to a more
appropriate group.

 

[Al Balmer]

If the answer is
a single sentence or something innocuous like that, then the best
answer may be to answer the question directly along with redirection
to a better newsgroup.

1. The single sentence answer may be wrong, and not caught by others
in the group because they aren't the people who know the subject. When
that wrong answer is given with apparent authority, chances are the
questioner will not follow up with the suggested group.

2. People participate in groups to learn more about the subject of the
group. By answering the off-topic question here, you are depriving the
people in the group where the question would be topical.

3. You are encouraging the questioner to come back with still more
off-topic questions.

In general, answering off-topic questions is doing a disservice to the
questioner. Send him to the right place. If you have the expertise and
want to answer the question, don't be shy. Redirect the questioner,
then answer the question where others may be interested in the answer,
may provide a different slant, or, heaven forbid, even correct the
advice you give.

 

[Old Wolf]

Any topicality stance is bound to have advantages *and* disadvantages. So
please think carefully before weighing in too heavily in favour of a
particular stance!

This group is already high-volume, by any reasonable
definition of the term. There are more than 100 posts
a day, I think.

Any loosening of the current topicality 'rules'
(i.e. other than your groups P,N,C) will only
make it harder to find and read the good posts.

 

[Default User]

Al Balmer wrote:

In general, answering off-topic questions is doing a disservice to the
questioner. Send him to the right place. If you have the expertise and
want to answer the question, don't be shy. Redirect the questioner,
then answer the question where others may be interested in the answer,
may provide a different slant, or, heaven forbid, even correct the
advice you give.

I agree with this. One way is to provide your answer, with the
"correct" newsgroup added to distribution and follow-ups set there.




Brian

 

[CBFalconer]

You are probably part of the small minority of the small minority
of C programmers who know what pure ISO C is who use it...

Most C programmers these days will be doing embedded and DSP work,
which invariably makes heavy use of the extensions provided by the
vendor for the specific target. I'm not saying that most of the
code for these environments can't be written in standard C, with
platform specifics confined to separate modules (I do this and
encourage others to do the same), but that is simply isn't.

So I think that while encouraging standard C, a group such as this
should cater for all C programmers and not pounce on any
non-standard code like a pack of wolves. By all means point out a
more correct way, but don't let the corrections swamp the often
simple answer to the original question. All too often threads
here degenerate into what is and what isn't standard C long after
the original question has been answered.

How about we all try to answer the specific questions asked first,
then point out how to correct non-standard forms? I'm sure it
wouldn't be too hard to make c.l.c a more friendly place.

This is a much more reasonable attitude. The problem is to avoid
letting it get out of hand. At the same time such answers
(basically reworking to standard C) are often totally unclear,
because the description is in terms of some off-beat
implementation, whose characteristics can at most be guessed at.
We aren't going to get clear problem descriptions from newbies.

We will probably get closest by pushing top-down programming. I.e.
write the program, dependent on several described routines. Write
those routines dependent on further routines. At some point
separate the herd of subservient routines into standards conforming
and non-standards conforming. With care, the non-standard stuff
should be small, and left up to the querier. The newbie will learn
all sorts of things from the process.

An awkward portion will be getting across what is, and is not,
standard. Things like "go read N1124" won't cut it, but "get it
and periodically search it" may help.

 

[CBFalconer]

.... snip ...

On the other hand, if the trolls would stop trolling, and if certain
non-trolls would stop complaining about attempts to encourage
topicality, I believe that the signal-to-noise would improve
dramatically.

Well, the PLONK file is a very rough approximation to that.

 

[CBFalconer]

.... snip ...

There is a header file foo.h, which defines a macro like this:

#define MAGIC_CHARACTER 'x'

The main program #includes foo.h and does some stuff that depends
on which character is selected to be magic. The intent is that the
user can change the x in the header file and recompile to get a
different result.

I would like to create a log file whose name contains the magic
character. If MAGIC_CHARACTER had been defined as a string ("x"
instead of 'x') I could do this:

logfp=fopen(MAGIC_CHARACTER ".log", "w");

How about:

#define MAGIC_CHAR 'x'
#define MAGIC_STRG # (MAGIC_CHAR, '\0')

use as desired.

 

[Al Balmer]

I was referring to the common form of
question where there is an obvious C language problem, but the posted
code contains something non standard, say <conio.h> or <curses.h>. More
often than not, these are dismissed as off-topic by virtue of the
platform specific code when there is a simple platform neutral answer.

Perhaps I read a different mix than you, but it seems just the
opposite to me. Many responders go out of their way to dig out the
question about C that's buried deep in the seemingly off-topic morass.
There may be some who dismiss the question because they didn't read
carefully, but that's why we allow more than one answer

More than once, I've skimmed, then skipped, a long message about
problems using some specialized library on Windows, then gone back
after I read a reply by someone who discerned the real question <g>.

 

[Al Balmer]

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.

If I had a safety critical issue that depended on particular knowledge
of the above projects, I certainly wouldn't depend on answers I got in
c.l.c., and I certainly hope that you wouldn't, either. In case you
do, please name the products involved, so I can avoid them ;-)