The C Programming Language: Third Edition

[Kenny McCormack]

<posted & mailed>

Rudolf said:


It doesn't.

I wonder what import you attach to that statement? I.e., why is it
important to assert it?

Anyway, regardless of what you call it, there is a document floating
around, cited often here, that basically says what is and isn't allowed
here. Whether or not it is officially sanctified as a "charter" is not
really relevant. My point is that the concept certainly exists.

 

[Kenny McCormack]

No it's not. It is written with a particular veiw point and some
regulars would disagree with parts.

If 100% agreement were necessary for a "charter" to exist, there would
be no "charters". Anyway, as I mention elsewhere, whether or not you
choose to sanctify it with that label, it's still (effectively) a charter.

It has no more or less standing than any one else's view on what this NG
is about. It is certainly no replacement for a charter.

You certainly can't deny that there is a strong, religious POV that has
been allowed to become dominant here.

 

[Morris Dovey]

Kenny McCormack (in [email protected]) said:

| In article <[email protected]>,
|| <posted & mailed>
||
|| Rudolf said:
||
||| In article <[email protected]>,
||| (e-mail address removed) (Kenny McCormack) wrote:
|||
|||| Then why are you posting here? Haven't you read the charter/FAQ?
|||
||| I didn't realize this group had a charter.
||
|| It doesn't.
|
| I wonder what import you attach to that statement? I.e., why is it
| important to assert it?
|
| Anyway, regardless of what you call it, there is a document floating
| around, cited often here, that basically says what is and isn't
| allowed here. Whether or not it is officially sanctified as a
| "charter" is not really relevant. My point is that the concept
| certainly exists.

The concept exists; but the document does not exist and never has.
Control of what's allowed, as much as that ever could actually be
controlled, is in the hands of the participants - and the amount of
influence that any one participant can exert varies according to other
participants estimation of that participant's knowledge, expertise,
and constructive attitude.

The whole lash-up is informal, hierarchical, and very real. The more
esteem one has earned, the more influence one can exert and the more
topical latitude is allowed by the group as a whole.

 

[Richard Heathfield]

Kenny McCormack said:

I wonder what import you attach to that statement?

The same de facto import that I attach to any true statement.

I.e., why is it important to assert it?

Why is it important to question how important it is to assert it? (And loop
until bored.)

Anyway, regardless of what you call it, there is a document floating
around, cited often here, that basically says what is and isn't allowed
here.

Really? I've been subscribing to clc since 1998, and I've never seen such a
document.

 

[Keith Thompson]

Bollox!

ADVOCATED BY *SOME* of the regulars. Regulars who chase off any newbie
they don't like.

There are several opposing views on what is On Topic here.

There are a few trolls (I emphatically do not include you in that
group) who don't care about any topicality guidelines, and probably
would continue not to care if they were changed.

There are a few more rational posters (including you) who believe that
the current widely accepted set of topicality guidelines should be
changed. But you, in particular, have not presented any specific
suggestions for what changes should be made. If you can come up with
a coherent proposal, perhaps something like a proposed charter, I'm
sure most of us would be willing to discuss it. Until then, what
we've got is what we've got.

We have something very much like a charter now, because a group of
regulars have made the effort to write it. (I didn't participate in
this myself.) If you want it changed, the ball is in your court.

 

[santosh]

Bollox!

ADVOCATED BY *SOME* of the regulars. Regulars who chase off any newbie
they don't like.

You're right. I should have said "some of the regulars".

There are several opposing views on what is On Topic here.
Yes.


No it's not. It is written with a particular veiw point and some
regulars would disagree with parts.

Then instead of answering to sporadic debates over the same issue, why
not create another wiki to represent the more "liberal" regulars, say
wiki.clc.liberated?

It has no more or less standing than any one else's view on what this NG
is about. It is certainly no replacement for a charter.

Since there is no formal charter and since "Rudolf" did ask for
pointers, this is the best I could come up with. I should've probably
been more precise with my wording.

As you say, this group is unmoderated so no one can actually enforce
anything and if some contributors feel the attitude of the "regulars"
is too restrictive, they're always free to try and change that by
encouraging the opposite.

Personally though, I feel that we should draw the line somewhere. C is
a very widely implemented language and if all remotely C related posts
were allowed, the group might just turn into a mess and spammer's
paradise. But it's just _my_ opinion of course.

But the line for topicality has to be drawn somewhere and, IMHO, the
boundaries of the C standard is a good place. If not, an arbitrary
decision would be confusing and even more controversial. What should be
deemed topical? C as it's implemented on PCs, or embedded C, or
mainframe implementations or all or any two of them? Or should _all_ C
related questions be allowed, like the recent "Power Builder to C#
porting" query?

food for thought...

 

[Richard Heathfield]

Keith Thompson said:

We have something very much like a charter now,

We do? When did that happen?

because a group of regulars have made the effort to write it.

When was it agreed that clc needed a charter? Who wrote it, specifically?
When was it voted on?

(I didn't participate in this myself.)

Who did?

If you want it changed, the ball is in your court.

Why would we need to change a non-normative document?

 

[Keith Thompson]

Keith Thompson said:



We do? When did that happen?


When was it agreed that clc needed a charter? Who wrote it, specifically?
When was it voted on?


Who did?


Why would we need to change a non-normative document?

I'm referring to the "Introduction to comp.lang.c" document at
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>, and other
documents on that site.

It's certainly not a charter in any formal sense, but it does seem to
reflect the consensus about what's topical here and what's not, and
many of us cite it when suggesting that a particular post is
off-topic.

If the consensus about what's topical here were to change, I hope that
any such changes would be reflected in that document. (I'm not
suggesting that any changes should be made.)

A formal charter is typically written before a newsgroup is created,
and can be cited as an authoritative source of topicality rules.
(Well, as authoritative as anything can be in an unmoderated group.)
The CLC wiki, on the other hand, is derived from the consensus on the
group rather than being the basis for it -- but it still, IMHO, serves
much of the same purpose that a charter would if we had one.

 

[Mark McIntyre]

Right. But it's the only ISO-conforming mode that implementation has, and
I'm not about to drop conformance checking just so that I can have borken
one-line comments.

I've no problem with that, but its still incorrect to say that the
compiler doesn't support the feature.

--
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

 

[Mark McIntyre]

Mark McIntyre said:


No, he just has a good memory.

He's stating stuff about how you work which only you can state with
certainty, and IMHO he can't use it as a basis for an argument.

No, he's not suggesting any such thing; he is merely reporting what actually
happens.


Mark, he's /right/. Please don't call him silly for being right.

I called him silly for being irrelevant.

I invoke
the compiler in C90 conforming mode for portability reasons. Note that, on
the implementation I use, there *isn't* a C99-conforming mode.

Absolutely. You *deliberately* invoke it in a non-conforming way and
*gasp* it doesn't conform.

Frankly thats a silly point to raise when claiming the compiler
doesn't support a feature. You could as well say it doesn't support
Fortran77 or Algol syntax. Of /course/ it doesn't, if you don't invoke
it with the right flags.

So you're silly, Keith is silly and I'm silly for continuing this
childish debate.
<EOT>
--
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

 

[Mark McIntyre]

There are degrees of portability. If I refer to something as
"portable", without qualification, I probably mean what you refer to
as "maximally portable". I don't know what distinction you're trying
to make.

I think you do, perfectly. However I'm quite disintrerested in
continuing this discussion with someone who seems to be producing
argumentation merely for its own sake.
--
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

 

[Keith Thompson]

I've no problem with that, but its still incorrect to say that the
compiler doesn't support the feature.

Yes, it is. That's probably why he didn't say it.

What Richard wrote upthread was:

[...] I do know that the C compiler that I habitually use, the
binary of which is dated 23 March 2002, correctly rejects //
"comments" when invoked in conforming mode.

What was your problem again?

 

[Mark McIntyre]

GCC is NOT C99 compliant, neither is Intel C.... like many they are
"working towards"

Nobody said it was. Please try to keep with the thread.
--
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

 

[Keith Thompson]

He's stating stuff about how you work which only you can state with
certainty, and IMHO he can't use it as a basis for an argument.

I'm re-stating stuff that he's already stated with certainty, and
which I have absolutely no reason to doubt. I have no idea why you
think I can't use that as a basis for an argument.

I called him silly for being irrelevant.

I don't think I'll be able to convince you that what I wrote was
entirely relevant.

Absolutely. You *deliberately* invoke it in a non-conforming way and
*gasp* it doesn't conform.

No, he invokes it in *conforming* mode (i.e., conforming to C90), and
it *conforms* to C90.

Frankly thats a silly point to raise when claiming the compiler
doesn't support a feature. You could as well say it doesn't support
Fortran77 or Algol syntax. Of /course/ it doesn't, if you don't invoke
it with the right flags.

There is no set of flags that produces the behavior you seem to be
suggesting (supporting C90 plus "//" comments). That point seems
fairly obvious by now; the fact that it's obvious doesn't make it
either irrelevant or silly. Richard has good and valid reasons for
avoiding "//" comments, reasons which have been explained here at
great length. That's the point of the discussion in this subthread; I
have no idea why you're having a problem with that.

So you're silly, Keith is silly and I'm silly for continuing this
childish debate.

Feel free to stop, but don't expect anyone to refrain from correcting
misstatements of fact.

 

[Richard Heathfield]

Mark McIntyre said:

I've no problem with that, but its still incorrect to say that the
compiler doesn't support the feature.

Agreed, but it is /correct/ to say that the compiler doesn't ignore the
syntax error when invoked in C90-conforming mode.

We often talk about implementations, without always spelling out what that
means. I would argue that "implementation" is a holistic term, encompassing
not just "the compiler" but also the platform, the library, the version of
the library, the version of the compiler, and even the flags with which
that compiler (or, indeed, interpreter) is invoked. Thus, gcc is not just
/one/ implementation, but many - and which one you get depends at least in
part on which flags you set when invoking it. So "vanilla gcc", if you
like, /does/ accept // as an extension meaning "single line comment starts
here", whereas "gcc invoked with the flags that switch on C90 conformance"
does not.

 

[Keith Thompson]

I think you do, perfectly. However I'm quite disintrerested in
continuing this discussion with someone who seems to be producing
argumentation merely for its own sake.

And I am quite *uninterested* (look it up) in being called a liar.

You asked me if I was a mind reader because I repeated something that
Richard clearly stated, and now you claim to know what I do and do not
understand.

 

[Keith Thompson]

Keith Thompson <[email protected]> writes:

[60 lines deleted]

You've responded to an article I posted July 3, 2006. As far as I can
tell, your followup has nothing to do with the old discussion, so it
would have been much better to start a new thread.

Was there some point when the standards writers actually sat
down and decided to add library functions to the C standard

I presume that was the intent from the beginning.

- was there a set of library functions that were defined by
the earlier C implementations that the standards authors
included, and then expanded to accommodate legacy code of
later implementations.

The ANSI C Rationale is available in HTML format at
<http://www.lysator.liu.se/c/rat/title.html>. The introduction to the
Library section says:

The Base Document for this section of the Standard was the 1984
/usr/group Standard. The /usr/group document contains definitions
of some facilities which were specific to the UNIX Operating
System and not relevant to other operating environments, such
as pipes, ioctls, file access permissions and process control
facilities. Those definitions were dropped from the Standard.
Some other functions were excluded from the Standard because
they were non-portable or were ill-defined.

Other facilities not in the library Base Document but
present in many UNIX implementations, such as the curses
(terminal-independent screen handling) library were considered
to be more complex and less essential than the facilities of the
Base Document; these functions were not added to the Standard.

The C99 rationale is available in PDF format at

Has there been any effort to catalog the functions or
prototypes that came first or their system-dependent
implementations, and to decide what legacy code would be
forwardly compatible with the functions that appeared in C
libraries later, that the _authors_ (and not, strictly
speaking, the standards writers, etc., etc.), did not know
about of in advance, of course.

I'm not aware of any such effort.

[snip]

 

[Guest]

there's a regular poster who replies a week or so behind the times.
I'd vaguely assumed he was taking trips to Mars and had a bad
internet
connection. You on the other hand are over *two years* behind the
times.
Visit to pluto?

If Richard [Heathfield] wants to write conforming C90 code, he can specify a
certain set of options to gcc; gcc will then issue diagnostics for any
code that doesn't conform to C90.  (Or close enough; there's always
the possibility of bugs, but gcc seems to be reasonably solid in this
area.)  The resulting code, if gcc accepts it, is very likely to be
portable to any other conforming C90 implementation.

If he wants to write conforming C99 code using the full language, he
can't do it, since gcc doesn't support the full C99 language.  He can
write code in the subset of C99 that gcc supports, but such code won't
be portable, since other compilers may support different subsets of
C99; if his code depends on a certain C99 feature that gcc happens to
support, it might break on another compiler that doesn't happen to
support that particular feature (even if it supports a number of other
C99 features).

Was there some point when the standards writers actually sat
down and decided to add library functions to the C standard

yes. The ANSI standard for C was published in 1989. This is
often referred to in comp.lang.c as c89. c89 included the
library.

- was there a set of library functions that were defined by
the earlier C implementations that the standards authors
included,

yes. Kernighan and Richie in their book "The C Programming
Language" defined the C language (so-called K&R C) and many of
the library functions that were incorporportated into C89.
Other people added to the defacto standard C library.
This why it's a bit inconsistent.

and then expanded to accommodate legacy code of
later implementations.

the legacy implementaions were largely covered by the standard.
More functions were added in 1999 when ISO revised the standard.

Has there been any effort to catalog the functions or
prototypes that came first
c89?


or their system-dependent
implementations,

read a Unix implementation of the clib library.
If you care go and read free BSD for an an
implementaion of the C librrary.

and to decide what legacy code would be
forwardly compatible with the functions that appeared in C
libraries later, that the _authors_ (and not, strictly
speaking, the standards writers, etc., etc.), did not know
about of in advance, of course.

I've no idea what you are on a bout. The C standard
(89 and 99) defines a standard portable interface.
Parts of it have to be reimplemented for each platform.

Without going on too much about which functions came first,
ad infinitum, are there references and/or tutorials to the
various groups of functions - the printfs and scanfs, signal
handling, wide characters, etc., etc., - that not to be OT
in the discussion of writing of _actual_ C programs.  

read the standard. Or a good tutorial. Eg. K&R ed 2