Topicality

[Anders Wegge Keller]

Is there a general consensus(sp?) of what is and isn't topical in
this group? Appeals to the almighty orcle of google hints to the fact
that there isn't a firm definition. So I'd like to hear if talk about
C-analysis/parsing+modification tools like Coccinelle, clang, lint
etc. are frowned upon here or not?

 

[jacob navia]

Le 23/02/11 23:21, Anders Wegge Keller a écrit :

Is there a general consensus(sp?) of what is and isn't topical in
this group? Appeals to the almighty orcle of google hints to the fact
that there isn't a firm definition. So I'd like to hear if talk about
C-analysis/parsing+modification tools like Coccinelle, clang, lint
etc. are frowned upon here or not?

Of course not. That would be at last an interesting subject in this boring
group

 

[Keith Thompson]

Is there a general consensus(sp?) of what is and isn't topical in
this group? Appeals to the almighty orcle of google hints to the fact
that there isn't a firm definition. So I'd like to hear if talk about
C-analysis/parsing+modification tools like Coccinelle, clang, lint
etc. are frowned upon here or not?

In late September of 2009, Richard Heathfield posted a survey under
the subject "Should we broaden the topicality of this group?".
After much discussion, he posted a summary on 2007-10-02 under the
subject "Topicality discussion - summary". Both articles *should*
be available via Google Groups. (I haven't confirmed that they
actually are.)

<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction> has
a lengthy discussion of topicality guidelines for this newsgroup.
I personally agree with the point of view expressed there.

 

[Jens Thoms Toerring]

Is there a general consensus(sp?) of what is and isn't topical in
this group? Appeals to the almighty orcle of google hints to the fact
that there isn't a firm definition. So I'd like to hear if talk about
C-analysis/parsing+modification tools like Coccinelle, clang, lint
etc. are frowned upon here or not?

Wow, you've opened quite a can of worms-

There's no charter for clc as it already existed before
they became common. Thus there's no written manisfesto on
what's topical and what not, a nice reason for recurrent
flame-wars...

So, there's only some kind of consensus, with fightings
breaking out from time to time. The gist of this consensus
(not shared by all participants, obviously- is that the
group is about C as the language, mostly as defined by
the standard(s). E.g. third party libraries, just because
they are written in C, aren't. Same for system specific
extensions. Tools used for writing C also are not really
considered topical - unless, of course, their results in
C-specific questions. I.e. if lint claims something is an
error it's completely on-topic to discuss if this is really
an error. The question, on the other hand, of which options
to pass to lint to make it stop complaining about that con-
struct isn't. And if you have ideas on how to improve the
standard (instead of how to interpret it) comp.std.c is
probably the better place for a discussion.

I guess that will give you the idea. I consider this to be
reasonable since so many things are written in C that co-
vering too much ground in this group would make it rather
useless for discussions about C and all the dark corners
that exist. This is probably also due to the fact that I
learned really a lot (and am still learning) on how to
write platform-independent code from those discussions, so
that I personally would find it a pity if this would get
drowned out by discussions about all kinds of posts about
system-specific extensions, pecularities of some libraries
I will never use, tools I never heard and rather likelu
won't ever care about.

Of course, there will appear a lot of posts in a short time
calling me a member of the "regulars cabal" or a "sock pup-
pet" of some one else. Let the fireworks start;-)

Regards, Jens

 

[Anders Wegge Keller]

In late September of 2009, Richard Heathfield posted a survey under
the subject "Should we broaden the topicality of this group?".
After much discussion, he posted a summary on 2007-10-02 under the
subject "Topicality discussion - summary". Both articles *should*
be available via Google Groups. (I haven't confirmed that they
actually are.)

I can confirm that they are. Unfortunately my question seem to be a
bit orthogonal to that discussion.

<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction> has
a lengthy discussion of topicality guidelines for this newsgroup.
I personally agree with the point of view expressed there.

And for something neither covered by 1.3 What's topical in
comp.lang.c nor 1.4 What's not topical in comp.lang.c?

 

[Roberto Waltman]

... talk about C-analysis/parsing+modification tools like Coccinelle, clang, lint etc.

That is definitively topical in comp.compilers
It is a moderated group, and it often takes one or two days for posts
to show up, but the quality of the group makes it worth the wait.

 

[Tom St Denis]

 Is there a general consensus(sp?) of what is and isn't topical in
this group? Appeals to the almighty orcle of google hints to the fact
that there isn't a firm definition. So I'd like to hear if talk about
C-analysis/parsing+modification tools like Coccinelle, clang, lint
etc. are frowned upon here or not?

My 2 cents...

If it's a post about conforming to the C spec then it's bang on
target, if it's a post about a new feature that might interest C users
[e.g. diagnostics/optimizations] it's borderline on topic and IMHO
acceptable, if it's a post about arguing license semantics [GPLv3 vs
BSD, or whatever] then it's off-topic and not welcomed. If it's a
post ranting about this developer or that developer in different
compiler teams, not welcomed, etc.

Basically, if it's about the C language or of general use to a C
developer (about C, not just anything a developer might need, like
coffee or beer...) then it should be acceptable here. Anything else
is OT.

Tom

 

[Tom St Denis]

Le 23/02/11 23:21, Anders Wegge Keller a crit :


Of course not. That would be at last an interesting subject in this boring
group

comp.compilers is around.

Also, no offense, but your non-conforming compiler isn't all that
useful to most people. I sell C code for a living. Most customers
aren't even using the same processor let alone same compiler [or
version of the compiler] as I am. Conforming to a standard is what
makes my job possible.

If I insisted on using strict GNUisms or LCC-win32isms I'd be shit out
of luck in most circumstances.

Tom

 

[jacob navia]

Le 24/02/11 04:55, Tom St Denis a écrit :

comp.compilers is around.

Also, no offense, but your non-conforming compiler isn't all that
useful to most people.

And my compiler has nothing to do with whether we discuss about
C analysis tools or not. But you can't resist to try to
denigrate my work at each post.

I sell C code for a living.

fine. I sell C compilers.

Most customers
aren't even using the same processor let alone same compiler [or
version of the compiler] as I am. Conforming to a standard is what
makes my job possible.

Sure. And so what?
Not a single customer has asked me about C standard conformance.

If I insisted on using strict GNUisms or LCC-win32isms I'd be shit out
of luck in most circumstances.

Tom

Yes Tom. And (again) SO WHAT?

You do not like my compiler system?

Just do not use it.

 

[Malcolm McLean]

 Is there a general consensus(sp?) of what is and isn't topical in
this group?

Topicality is a problem in comp.lang.c

The formal topic of the group - the C language - is a bit too narrow.
There's a limit to what you can say about padding bytes and the ideal
width of an int.

The alternative topic - any program, algorithm or library written in C
- is too broad. So we need to show commonsense and good manners, and
keep the discussion sensibly focused.

 

[Tom St Denis]

Le 24/02/11 04:55, Tom St Denis a crit :






And my compiler has nothing to do with whether we discuss about
C analysis tools or not. But you can't resist to try to
denigrate my work at each post.

I was not being rude or denigrating. I was merely pointing out that a
non-conforming compiler isn't that useful to most developers. And
it's true. I didn't say it's worthless or whatever.

Also to the average clc reader it should definitely be far off topic
since what you have isn't even a C compiler anymore.

Tom

 

[Malcolm McLean]

Also, no offense, but your non-conforming compiler isn't all that
useful to most people.  I sell C code for a living.  Most customers
aren't even using the same processor let alone same compiler [or
version of the compiler] as I am.

No, the extensions are useless to you. Your situation isn't
particularly common.

 

[Chris H]

In message <[email protected]

I was not being rude or denigrating. I was merely pointing out that a
non-conforming compiler isn't that useful to most developers.

Conforming to what?

Also to the average clc reader it should definitely be far off topic
since what you have isn't even a C compiler anymore.

In which case most C compilers don't qualify.

 

[Kenny McCormack]

In message <[email protected]


Conforming to what?


In which case most C compilers don't qualify.

This "TSD" character really is a nut-job isn't he?

I'm glad you're taking the time to debate with him and point out his
whackiness.

For the benefit of the new-users, of course...

 

[Kenny McCormack]

Topicality is a problem in comp.lang.c

The formal topic of the group - the C language - is a bit too narrow.
There's a limit to what you can say about padding bytes and the ideal
width of an int.

How could you forget the real meat of this group, namely, prototyping main()
and not casting the return value of malloc()?

 

[Tom St Denis]

In message <[email protected]


Conforming to what?

The ISO C spec.

In which case most C compilers don't qualify.

GCC conforms to C90 afaik, it doesn't fully support C99 but it
supports a useful subset of it (basically most of it except for some
of the more esoteric features). Things like hybrid classes and
bignums/etc are a giant departure.

In many cases, GNUisms like inline asm are nice but not a selling
feature of GCC. It's ubiquity and adherence to standards makes it
useful.

Tom

 

[Tom St Denis]

This "TSD" character really is a nut-job isn't he?

I'm glad you're taking the time to debate with him and point out his
whackiness.

For the benefit of the new-users, of course...

I'm glad you took the time to contribute to this thread.

Tom

 

[Tom St Denis]

Also, no offense, but your non-conforming compiler isn't all that
useful to most people.  I sell C code for a living.  Most customers
aren't even using the same processor let alone same compiler [or
version of the compiler] as I am.

No, the extensions are useless to you. Your situation isn't
particularly common.

I've never had a customer, ever, ask about using compiler extensions
in library code I was providing them. Except to ensure I *wasn't*
using them.

Tom

 

[Chris H]

In message <[email protected]

The ISO C spec.

Which one specifically?

GCC conforms to C90 afaik,

Which GCC? There are many.

it doesn't fully support C99 but it
supports a useful subset of it (basically most of it except for some
of the more esoteric features).

Esoteric to you essential to others. So it is NOT a C99 compiler any
more than any other compiler is. Therefore it does not conform to the
"ISO C spec" It also has extensions of its own.

So in that regard it is the same as all the others like for example LCC

In many cases, GNUisms like inline asm are nice but not a selling
feature of GCC.
Agreed.

It's ubiquity and adherence to standards makes it
useful.

CRAP there are many GCC compilers. They do not adhere to the ISO-c
standard any better than any other compiler out there and a lot worse
than most. It is not even a particularly efficient compiler system

 

[jacob navia]

Le 24/02/11 14:58, Tom St Denis a écrit :

Also, no offense, but your non-conforming compiler isn't all that
useful to most people. I sell C code for a living. Most customers
aren't even using the same processor let alone same compiler [or
version of the compiler] as I am.

No, the extensions are useless to you. Your situation isn't
particularly common.

I've never had a customer, ever, ask about using compiler extensions
in library code I was providing them. Except to ensure I *wasn't*
using them.

Tom

Then, do not use compiler extensions.

The question is however:

Why do you need to denigrate my work at each post?

My compiler provides an ANSI compatible mode. Use that.

But of course that is not useful to you because some other obscure
reason that you will find in a second after you read this post.