What is on topic here
jacob navia
and the C language in general.
This includes (but is not limited to)
o linking problems
o debugging problems
o makefile problems related to the building of a c program
o compiling and compiler related questions
Most of the people that argue otherwise and want to restrict
the scope of this group are part of a small self proclaimed
group that thinks it can restrict the scope of this group
to C89.
If you look at their recent posting history you will see that
they are the principal originators of completely off topic
conversations here (the endless spinoza111 threads are a proof
of that).
To avoid clutter I will not answer any of their answers, if any.
jacob
Seebs
> This group is about building C progreams
> and the C language in general.
What is your source for this claim, or authority to make it?
You, and other people, make claims about what this group is about.
Why should someone believe your claims over the other claims that
have been advanced?
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Richard Heathfield
> This group is about building C progreams
Perhaps it should be, but it currently isn't.
> and the C language in general.
I would say it's currently about the C language in particular. And there
are only two internationally recognised definitions of C - ISO 9899:1990
and ISO 9899:1999.
> This includes (but is not limited to)
>
> o linking problems
> o debugging problems
> o makefile problems related to the building of a c program
> o compiling and compiler related questions
That's a view, but I think you'll find it's not a majority view. If
you're arguing that topicality should be widened, well, I agree
(although we don't necessarily agree about the direction of that
widening) - but the majority view is against us. Or at least, it was,
last time anyone bothered to check.
> Most of the people that argue otherwise and want to restrict
> the scope of this group are part of a small self proclaimed
> group that thinks it can restrict the scope of this group
> to C89.
No, most of the people who argue otherwise are the majority of
contributors to the group. In a democracy, they win and we lose. That's
life.
> If you look at their recent posting history you will see that
> they are the principal originators of completely off topic
> conversations here (the endless spinoza111 threads are a proof
> of that).
If you look at the endless spinoza1111 threads, you'll see that their
off-topic aspects are principally originated by spinoza1111.
> To avoid clutter I will not answer any of their answers, if any.
Can you also avoid clutter by shutting up about lcc-win32? This is a
newsgroup about C, not a personal blog for your compiler. If you want a
personal blog for your compiler, your Web site would be a good bet.
Failing that, try comp.compilers.lcc.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Gareth Owen
> If you look at their recent posting history you will see that they are
> the principal originators of completely off topic conversations here
> (the endless spinoza111 threads are a proof of that).
Actually, spinoza111 tends to be the principal originator of most of the
spinoza111. Having said that, Seebs and Richard Heathfield are his
facilitators -- more than happy to continually goad, taunt and mock him,
even though they *must* know by now that he cannot have his opinions
changed by them.
Ian Collins
>
> If you look at the endless spinoza1111 threads, you'll see that their
> off-topic aspects are principally originated by spinoza1111.
And principally egged on by Richard Heathfield!
--
Ian Collins
Seebs
> Actually, spinoza111 tends to be the principal originator of most of the
> spinoza111. Having said that, Seebs and Richard Heathfield are his
> facilitators -- more than happy to continually goad, taunt and mock him,
> even though they *must* know by now that he cannot have his opinions
> changed by them.
Actually, once I figured out that he was essentially incapable of processing
data in a functional way, I plonked him and stopped responding. That woulda
been weeks ago, I think.
So I don't think I count as a facilitator now. I tried to argue with him
for a while, tried to plumb the madness for a while in the hopes that it
would at least yield interesting ways of being wrong about C, and then
concluded that the marginal cost of getting an interesting observation from
arguing with him was too high to justify it.
Richard Heathfield
> jacob navia <ja...@nospam.org> writes:
>
>> If you look at their recent posting history you will see that they are
>> the principal originators of completely off topic conversations here
>> (the endless spinoza111 threads are a proof of that).
>
> Actually, spinoza111 tends to be the principal originator of most of the
> spinoza111. Having said that, Seebs and Richard Heathfield are his
> facilitators
I don't know whether you've noticed yet, but I've more or less stopped
doing that. Why? Well, I'd tell you, only it would probably count as
more "facilitation".
Richard Heathfield
If you were subjected to the same level of vilification by this guy as I
am, perhaps you might respond as I have responded in the past. But
recently I've backed off from responding to these attacks. Did you
notice that, or were you too busy nurturing your preconceptions?
Gareth Owen
> Actually, once I figured out that he was essentially incapable of
> processing data in a functional way, I plonked him and stopped
> responding. That woulda been weeks ago, I think.
I'm very glad, and I withdraw that remark unconditionally.
I didn't notice, because spinny's threads stopped appearing in my
newsreader some time ago.
Gareth Owen
> I don't know whether you've noticed yet,
I hadn't (Gnus score files rock).
> but I've more or less stopped doing that.
Good. That's wholly to your credit.
Nick
> Ian Collins wrote:
>> Richard Heathfield wrote:
>>>
>>> If you look at the endless spinoza1111 threads, you'll see that
>>> their off-topic aspects are principally originated by spinoza1111.
>>
>> And principally egged on by Richard Heathfield!
>
> If you were subjected to the same level of vilification by this guy as
> I am, perhaps you might respond as I have responded in the past. But
> recently I've backed off from responding to these attacks. Did you
> notice that, or were you too busy nurturing your preconceptions?
I did notice it, and I'm very grateful; thank you.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Seebs
> I didn't notice, because spinny's threads stopped appearing in my
> newsreader some time ago.
I think Richard Heathfield has also cut back quite a bit. He's posted an
occasional response, but honestly, most of the recent ones I've noticed
were cases where Mr. Heathfield was making a relevant, possibly interesting,
point.
There is some topicality to some of Spinoza's rants. I would guess that
many readers could have learned something from the detailed discussion of
how the C preprocessor works, when constant folding does and doesn't happen,
and so on. (To be fair, I'd have assumed most people would have known it,
but there are certainly newbies here, and I believe it theoretically
possible that some of them know less about C than Spinny.)
frank
> jacob navia wrote:
>> This group is about building C progreams
>
> Perhaps it should be, but it currently isn't.
>
>> and the C language in general.
>
> I would say it's currently about the C language in particular. And there
> are only two internationally recognised definitions of C - ISO 9899:1990
> and ISO 9899:1999.
>
>> This includes (but is not limited to)
>>
>> o linking problems
>> o debugging problems
>> o makefile problems related to the building of a c program
>> o compiling and compiler related questions
>
> That's a view, but I think you'll find it's not a majority view.
snip
I would dispute that statistic, Richard.
>> Most of the people that argue otherwise and want to restrict
>> the scope of this group are part of a small self proclaimed
>> group that thinks it can restrict the scope of this group
>> to C89.
>
> No, most of the people who argue otherwise are the majority of
> contributors to the group. In a democracy, they win and we lose. That's
> life.
I've heard that Heathfield wants to bring back C89, but I've never read
it myself in here. Maybe I'm missing these threads. Keith has talked
about them. The closest I can come to the motivation for this
allegation is that he compiles with -ansi (ten years ago).
>
>> If you look at their recent posting history you will see that
>> they are the principal originators of completely off topic
>> conversations here (the endless spinoza111 threads are a proof
>> of that).
>
> If you look at the endless spinoza1111 threads, you'll see that their
> off-topic aspects are principally originated by spinoza1111.
I think we all hope that spinoza finds a more healthy conduit for his
considerable natural gifts than whatever he's writing here.
>
>> To avoid clutter I will not answer any of their answers, if any.
>
> Can you also avoid clutter by shutting up about lcc-win32? This is a
> newsgroup about C, not a personal blog for your compiler. If you want a
> personal blog for your compiler, your Web site would be a good bet.
> Failing that, try comp.compilers.lcc.
>
I learned a lot from jacob's compiler. I wish I could have been more of
a funder.
--
frank
Antoninus Twink
> jacob navia wrote:
>> This group is about building C progreams
>
> Perhaps it should be, but it currently isn't.
You are wrong. It currently is. Look back through the threads from the
past few months: you'll find that however much you and your friends
stamp up and down and shout about it, there has been *plenty* of active
discussion, with participants from well outside the circle of those you
call "trolls", about the wider context of C.
You think of clc as a platonic ideal. Try looking as it as it actually
is today.
>> and the C language in general.
>
> I would say it's currently about the C language in particular. And
> there are only two internationally recognised definitions of C - ISO
> 9899:1990 and ISO 9899:1999.
As has been said before, the name of this group suggests that it is
about /all/ versions of C, not just ISO C. De facto, it's "currently
about" a wide variety of C issues, because it's a simple fact that there
are currently lots of active threads about a wide variety of C issues.
>> This includes (but is not limited to)
>>
>> o linking problems
>> o debugging problems
>> o makefile problems related to the building of a c program
>> o compiling and compiler related questions
>
> That's a view, but I think you'll find it's not a majority view. If
> you're arguing that topicality should be widened, well, I agree
> (although we don't necessarily agree about the direction of that
> widening) - but the majority view is against us. Or at least, it was,
> last time anyone bothered to check.
http://en.wikipedia.org/wiki/Self-selecting_sample ...
...and on two levels:
1) lots of people who would enjoy reading and perhaps contributing to
clc if it was more relevant to real-world programming will have been
driven away from the group years ago by the aggressive behavior of the
"topicality" police.
2) of those who are interested in wider C questions and still read the
group, why would they want to take part in an obviously rigged and
meaningless survey conducted by the not-exactly-impartial Heathfield? I
know I didn't. Must better to make the topicality relaxation a fait
accompli by just getting on and answering real-world C questions.
>> Most of the people that argue otherwise and want to restrict
>> the scope of this group are part of a small self proclaimed
>> group that thinks it can restrict the scope of this group
>> to C89.
>
> No, most of the people who argue otherwise are the majority of
> contributors to the group. In a democracy, they win and we lose.
> That's life.
clc is not a democracy. You may wish that you were president and that
Kiki and Sossman were your loyal senators, but it simply isn't so. There
is no government here - each person stands on what he or she posts.
The only way to control a Usenet group is through moderation. This group
is unmoderated.
> If you look at the endless spinoza1111 threads, you'll see that their
> off-topic aspects are principally originated by spinoza1111.
Are you arguing that as long as someone else struck the match, it's
perfectly fine to throw gasoline onto the flames? Interesting.
> Can you also avoid clutter by shutting up about lcc-win32? This is a
> newsgroup about C, not a personal blog for your compiler. If you want a
> personal blog for your compiler, your Web site would be a good bet.
> Failing that, try comp.compilers.lcc.
Glad you managed to get that nasty little paragraph of abuse in,
Heathfield. It would be a shame if you missed an opportunity to put the
boot in to Jacob - otherwise we might forget what a vile little weasel
you really are.
Keith Thompson
> Richard Heathfield wrote:
>> jacob navia wrote:
>>> Most of the people that argue otherwise and want to restrict
>>> the scope of this group are part of a small self proclaimed
>>> group that thinks it can restrict the scope of this group
>>> to C89.
>>
>> No, most of the people who argue otherwise are the majority of
>> contributors to the group. In a democracy, they win and we
>> lose. That's life.
>
> I've heard that Heathfield wants to bring back C89, but I've never
> read it myself in here. Maybe I'm missing these threads. Keith has
> talked about them. The closest I can come to the motivation for this
> allegation is that he compiles with -ansi (ten years ago).
That's irrelevant to the point. I don't think anyone seriously
disputes that both C89/C90 and C99 are topical. It's also generally
accepted that K&R C is topical, as are even earlier versions, mostly
for historical interest. We've even had discussions of B and BCPL,
the ancestors of C.
[...]
Back in late September of 2007, Richard Heathfield started a thread
with the subject "Should we broaden the topicality of this group?".
Richard himself favored doing so, but the majority of those who
participated in the discussion expressed the opinion that the
topicality guidelines should remain as they are (i.e., as advocated by
the "regulars"). Richard posted a summary of the discussion
on 2007-10-02, subject "Topicality discussion - summary".
Google Groups URLs:
http://groups.google.com/group/comp.lang.c/browse_frm/thread/306800faf6c30d43/a642808d3bf37773
http://groups.google.com/group/comp.lang.c/browse_frm/thread/32c4358dc0307344/faa1895ecbce478b
It's interesting to note that many of those who complain most loudly
about the topicality guidelines being too strict were participating in
the newsgroup at the time, but did not choose to participate in the
discussion.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ian Collins
> Ian Collins wrote:
>> Richard Heathfield wrote:
>>>
>>> If you look at the endless spinoza1111 threads, you'll see that their
>>> off-topic aspects are principally originated by spinoza1111.
>>
>> And principally egged on by Richard Heathfield!
>
> If you were subjected to the same level of vilification by this guy as I
> am, perhaps you might respond as I have responded in the past. But
> recently I've backed off from responding to these attacks. Did you
> notice that, or were you too busy nurturing your preconceptions?
I kill-filed him long ago, so I don't see his rants. Unfortunately my
preconceptions have wilted, I forgot to water them.
--
Ian Collins
Keith Thompson
> This group is about building C progreams
> and the C language in general.
>
> This includes (but is not limited to)
>
> o linking problems
> o debugging problems
> o makefile problems related to the building of a c program
> o compiling and compiler related questions
>
> Most of the people that argue otherwise and want to restrict
> the scope of this group are part of a small self proclaimed
> group that thinks it can restrict the scope of this group
> to C89.
I disagree, as I've said at length in the past.
> If you look at their recent posting history you will see that
> they are the principal originators of completely off topic
> conversations here (the endless spinoza111 threads are a proof
> of that).
>
> To avoid clutter I will not answer any of their answers, if any.
At least two regular posters have participated in pointless debates
with spinoza1111, but have stopped doing so, or at least substantially
reduced their participation. You might want to give them credit for
improved behavior rather than refusing to talk to them.
frank
That was an interesting gander into the past, Keith. I took a look at
the names, and I know all of them. It didn't seem like a very large
array in my head. Matter of fact, it seemed like a small one.
Let me quote of one of the better usenet netizens I've ever encountered:
27. Peter J. Holzer
View profile
More options Sep 30 2007, 10:18 am
Newsgroups: comp.lang.c
From: "Peter J. Holzer" <hjp-usen...@hjp.at>
Date: Sun, 30 Sep 2007 19:18:25 +0200
Local: Sun, Sep 30 2007 10:18 am
Subject: Re: Should we broaden the topicality of this group?
Reply to author | Forward | Print | Individual message | Show original |
Report this message | Find messages by this author
On 2007-09-30 14:14, CBFalconer <cbfalco...@yahoo.com> wrote:
- Hide quoted text -
- Show quoted text -
> "Peter J. Holzer" wrote:
>> CBFalconer <cbfalco...@yahoo.com> wrote:
>>> "Peter J. Holzer" wrote:
>>>> Basically, I think the topic of this group should be "the language
>>>> C in the real world", as opposed to "the language C as described
>>>> in the standard", which is on-topic in comp.std.c. In the real
>>>> world, C is a group of dialects, and while the principal focus
>>>> should be on elements of the standard language, I see nothing
>>>> wrong in discussing the idiosyncracies of a specific dialect.
>>> The problem with that is that there is no standard of correctness,
>> Where a standard of correctness is needed, conformance to C90 or
>> C99 can be used.
> Oh? You mean you recommend incorrect code?
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.
hp
For germans, hanging on to even high german is ridiculous.
--
frank
Antoninus Twink
> Back in late September of 2007, Richard Heathfield started a thread
> with the subject "Should we broaden the topicality of this group?".
[snip nonsense]
> It's interesting to note that many of those who complain most loudly
> about the topicality guidelines being too strict were participating in
> the newsgroup at the time, but did not choose to participate in the
> discussion.
Did you miss my post elsewhere in the thread, Keith? It debunks your
ridiculous lies.
<quote>
http://en.wikipedia.org/wiki/Self-selecting_sample ...
...and on two levels:
1) lots of people who would enjoy reading and perhaps contributing to
clc if it was more relevant to real-world programming will have been
driven away from the group years ago by the aggressive behavior of the
"topicality" police.
2) of those who are interested in wider C questions and still read the
group, why would they want to take part in an obviously rigged and
meaningless survey conducted by the not-exactly-impartial Heathfield? I
know I didn't. Must better to make the topicality relaxation a fait
accompli by just getting on and answering real-world C questions.
</quote>
Flash Gordon
> Richard Heathfield wrote:
>> jacob navia wrote:
<snip>
>>> Most of the people that argue otherwise and want to restrict
>>> the scope of this group are part of a small self proclaimed
>>> group that thinks it can restrict the scope of this group
>>> to C89.
>>
>> No, most of the people who argue otherwise are the majority of
>> contributors to the group. In a democracy, they win and we lose.
>> That's life.
>
> I've heard that Heathfield wants to bring back C89, but I've never read
> it myself in here. Maybe I'm missing these threads. Keith has talked
> about them. The closest I can come to the motivation for this
> allegation is that he compiles with -ansi (ten years ago).
The reason you don't remember Richard Heathfield (or any one) trying to
restrict the group to C89 is that no one has tried to do that. It is
Jacob miss-representing what other people have said, which is that there
are still very few C99 implementations, so C89/C90/C95 is more portable,
and it is useful for people to know when they are restricting portability.
A lot of companies use MS VCC for compiling C code, and that does not
implement C99, so earlier (theoretically obsolete) versions of the C
standard are still very important. I'm hoping that the new stuff being
put in to C1x will be enough to kick MS in to moving forward and
implementing the current standard, which would probably push other
companies in to supporting it.
--
Flash Gordon
john
AT: I think I remember reading a post from Keith saying that he had you
killfiled, so that could explain why he missed your post.
I wish you'd BOTH stop this ad hominem personal bickering and spend more
time sharing your undoubted C expertise! And Jacob Navia and Rich
Heathfield too for that matter.
j.
Kenny McCormack
Point out one thread started by Mr. Nilges.
Thank you.
Antoninus Twink
> AT: I think I remember reading a post from Keith saying that he had you
> killfiled, so that could explain why he missed your post.
Keith doesn't have a killfile.
Kenny McCormack
...
>I wish you'd BOTH stop this ad hominem personal bickering and spend more
>time sharing your undoubted C expertise! And Jacob Navia and Rich
>Heathfield too for that matter.
As I've demonstrated many times, there is nothing topical here to
discuss - it simply doesn't exist - if (and assuming) that the word
"topical" is interpreted the way most people do. That is as synonymous
with "appropriate". I think it is clear in our hearts and minds that
"appropriate" is what we really mean when we say "topical".
Thus, it is not possible to discuss anything topical here other than:
1) topicality itself (which is what we all discuss, all the time)
2) language lawyering (which appeals only to fools)
Finally, note that the topicality police have changed their tune lately
(I've observed this previously, starting, I think, about 6 months to a
year ago) from one of "You are wrong (in a moral/religious sense) to
post that here" to "I won't help you if you post it here". But the net
effect is the same; the change is only superficial, and should fool no
one.
Kenny McCormack
I believe he has described in the past as a "mental killfile".
Colonel Harlan Sanders
(Kenny McCormack) wrote:
>Point out one thread started by Mr. Nilges.
>
>Thank you.
From: spinoza1111 <spino...@yahoo.com>
Newsgroups: comp.lang.c
Subject: C as deep blasphemy
Date: Wed, 30 Dec 2009 02:56:54 -0800 (PST)
From: spinoza1111 <spino...@yahoo.com>
Newsgroups: comp.lang.c
Subject: Comparision of C Sharp and C performance
Date: Sun, 27 Dec 2009 06:36:54 -0800 (PST)
From: spinoza1111 <spino...@yahoo.com>
Newsgroups: comp.lang.c
Subject: C is NOT significantly more efficient than C Sharp
Date: Sun, 27 Dec 2009 02:50:15 -0800 (PST)
From: spinoza1111 <spino...@yahoo.com>
Newsgroups: comp.lang.c
Subject: Peter Seebach's behavior as "moderator" of comp.lang.C
Date: Fri, 25 Dec 2009 04:04:15 -0800 (PST)
From: spinoza1111 <spino...@yahoo.com>
Newsgroups: comp.lang.c,comp.programming
Subject: Richard Heathfield's lie
Date: Thu, 24 Dec 2009 09:14:51 -0800 (PST)
etc, etc...
Of course, the last time someone claimed they couldn't find his posts,
he threatened them with libel.
Richard Tobin
Seebs <usenet...@seebs.net> wrote:
>> This group is about building C progreams
>> and the C language in general.
>What is your source for this claim, or authority to make it?
The same as everyone else's, of course.
>You, and other people, make claims about what this group is about.
>Why should someone believe your claims over the other claims that
>have been advanced?
No reason. But I don't recall you making similar comments in response
to assertions that comp.lang.c is for discussions of standardised C
only. Should only those with that view assert it?
Comp.lang.c is for discussion of the C language, including common
implementations and related tools (especially those on unix, where it
originated).
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Seebs
> The same as everyone else's, of course.
Well, I sort of assumed that, but I wondered if he had something special
in mind.
> No reason. But I don't recall you making similar comments in response
> to assertions that comp.lang.c is for discussions of standardised C
> only. Should only those with that view assert it?
I think anyone expecting other people to accept their pronouncements
should.
> Comp.lang.c is for discussion of the C language, including common
> implementations and related tools (especially those on unix, where it
> originated).
While this is certainly a conceivable topic for a newsgroup, I don't
see any evidence that this was the topic intended for comp.lang.c when
it was created.
Maybe the right thing to do is just do an RFC and get a charter approved
for comp.lang.c. The tricky part, historically, has been that C is used
widely enough that a great deal of content which is tangentially C-related
is of no interest to most C programmers.
If we allow anything that has the word "C" somewhere in a description of
what we're talking about, everyone who is interested in C can post topically,
but most of the posts will be uninteresting to them. If we allow only things
that are very narrowly and strictly about C89, nearly any C programmer will
find the discussion relevant, but there won't be very much of it.
The historical compromise has been to stick with the language (including
C78, C89, C99, C0X), but not to include implementation-specific details,
extensions, etcetera.
There are a handful of common examples of things which are currently
generally regarded as being off-topic. I'll review those.
1. gcc questions.
2. GNU C questions.
3. Borland Turbo C questions.
4. Visual C questions.
5. UNIX API questions (sockets, etc.)
6. Windows API questions.
7. "C++ as a better C" questions.
8. make and makefile issues.
(For whatever reason, the Objective-C users never seem to come here.)
1. gcc questions.
This is the category of questions like "how do I enable warnings" and similar
questions. The recent example would be frank asking for help using the
preprocessor. These questions are clearly much more topical in gnu.gcc.help
than they are here, IMHO. I think it would make the most sense for these
questions to be routed there, simply because they'll get better responses.
There's usually more overlap between these questions and similar questions
about g77, g++, and so on, in any event.
2. GNU C questions.
By contrast with gcc questions, these are questions about the GNU C language.
Because Intel's now implementing some of this, this isn't really specific to
gcc anymore. These questions could indeed be addressed in gnu.gcc.help, but
icc users might not think to look there. Also, often what's most of interest
is the question of how these features related to, say, similar features in
C99. (Consider a discussion on the semantic differences between GNU C89
inline functions and C99 inline functions.)
Which is to say, I think this is probably the best group for these questions;
they are fundamentally about the language, not about how to use a particular
program, they apply to multiple implementations and environments (you can
use GNU C in several different operating systems), and they are tied in to
the language in general.
3. Borland Turbo C questions.
Specifically, <graphics.h> and <conio.h>. I suspect these are still best
suited to comp.os.msdos.programmer -- but they've been durable enough that
it's hard to be sure. They do seem essentially fixed to a DOS-like
environment, and I've never heard of them being implemented elsewhere. The
big surprise, I think, would be that people using these programs on Windows
might not realize that they're interacting with the faux DOS environment.
4. Visual C questions.
I've yet to see one of these that wasn't more like a gcc question than a GNU
C question -- that is to say, a question solely about how to use the program,
rather than about the language it implements. (Except in that usage can
change what language it implements.)
5. UNIX API questions (sockets, etc.)
I work in this stuff all the time, so it's certainly relevant to me, but
fundamentally, it just isn't C-related. The questions I have about the
UNIX APIs are the same questions I have when I'm using them from perl or
Ruby. There's a perfectly good UNIX programmer newsgroup, and I think these
belong there.
6. Windows API questions.
Ditto, except that it's not particularly relevant to me. Certainly, there's
a better group.
7. "C++ as a better C" questions.
By consensus, this has been understood to belong in comp.lang.c++. Seems
fair to me.
8. make and makefile issues.
I am a little torn on this, because of course, this is my primary way of using
C, but it's also my primary way of using several other languages. I would
tend to think that comp.unix.shell or one of the similar groups would be a
better fit. There's enough differences between make implementations that
a platform-specific group is probably better anyway in most cases.
... So, thinking about it, I guess my belief is this: I think it makes sense
to allow and/or encourage discussion of extensions to the *language* here, but
not extensions to the *library* unless they are by nature portable. Jacob
Navia's container library is clearly topical here. Curses isn't.
Other people have thoughts on this?
Jens Thoms Toerring
> Comp.lang.c is for discussion of the C language, including common
> implementations and related tools (especially those on unix, where it
> originated).
Could you be so kind to define this somewhat more precisely?
I have no idea what exactly you mean with this and thus fol-
low this question with some elaborations of mine to give you
some hints what I am thinking and thus may not understand of
aboy your statement.
Take e.g. 'make'. It could be seen as such a tool (Jacob Navia
obviously does), but then 'make' can be (and is) used to do lots
and lots of things completely unrelated to compiling C programs.
And dozends of other tools come to mind that can be employed in
the compilation of C programs, so where to draw the line? More-
over, if someone is having troubles with 'make' (s)he will find
quite good support in comp.unix.programmer (and the same holds
for other UNIX tools), so I would prefer to have them discussed
over there. It's the same, of course, for Windows specific tools
- I don't think it would be useful to have long discussions here
on how to set up a "project" with a certain IDE in order to get
some stuff compiled with this special tool when there are other
places where this is one of the main topics.
Concerning common implementations: I don't mind at all if some-
one points out that some implementation does things this way or
some other way, using the leeway given by the C standard. This
can actually be very useful to make one aware of where expecta-
tions one may have derived from using only a small subset of the
available implementations can lead one astray. But for a full
blown discussion of how to do certain things with a certain im-
plementation clc IMHO isn't the right place - especially since
"common implementations" typically have their own newsgroups or
mailing lists etc. It might actually be more difficult for users
of *uncommon implementations* to find a good place to find the
informations they may be looking for;-)
My take on non-directly-C-related questions (including tools or
special features of implementations) is that those should be re-
directed to the proper places by those that feel to be experts
enough on the subject to know what the proper newsgroup/mailing
list is to be found, with perhaps one or two sentences hinting
at what's the most likely correct answer if such a short answer
is possible and seems to be likely to help the OP. In cases where
it's a mixture of a C-related questions with system/library/tool-
specific ones it should be pointed out as clearly as possible
where the borders are and an answer should concentrate as far as
possible on the C-aspects, in the end I think this will be more
helpful for the OP: while (s)he may not get everything on a silver
platter, it will help her/him to develop a mental picture of where
things belong to and thus save her/him from spending much time loo-
king in the wrong direction in the long run.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
Richard
> Richard Tobin <ric...@cogsci.ed.ac.uk> wrote:
>> Comp.lang.c is for discussion of the C language, including common
>> implementations and related tools (especially those on unix, where it
>> originated).
>
> Could you be so kind to define this somewhat more precisely?
> I have no idea what exactly you mean with this and thus fol-
> low this question with some elaborations of mine to give you
> some hints what I am thinking and thus may not understand of
> aboy your statement.
>
> Take e.g. 'make'. It could be seen as such a tool (Jacob Navia
> obviously does), but then 'make' can be (and is) used to do lots
It's not rocket science. This is a group where C programmers discuss SW
in C - language, support tools, tricks of the trade.
Ignore the topicality Nazis.
spinoza1111
> On Sat, 23 Jan 2010 13:27:46 +0000 (UTC), gaze...@shell.xmission.com
>
> (Kenny McCormack) wrote:
> >Point out one thread started by Mr. Nilges.
>
> >Thank you.
>
> Newsgroups: comp.lang.c
> Subject: C as deep blasphemy
> Date: Wed, 30 Dec 2009 02:56:54 -0800 (PST)
>
> Newsgroups: comp.lang.c
> Subject: Comparision of C Sharp and C performance
> Date: Sun, 27 Dec 2009 06:36:54 -0800 (PST)
>
> Newsgroups: comp.lang.c
> Subject: C is NOT significantly more efficient than C Sharp
> Date: Sun, 27 Dec 2009 02:50:15 -0800 (PST)
>
> Newsgroups: comp.lang.c
> Subject: Peter Seebach's behavior as "moderator" of comp.lang.C
> Date: Fri, 25 Dec 2009 04:04:15 -0800 (PST)
>
> Newsgroups: comp.lang.c,comp.programming
> Subject: Richard Heathfield's lie
> Date: Thu, 24 Dec 2009 09:14:51 -0800 (PST)
>
> etc, etc...
>
> Of course, the last time someone claimed they couldn't find his posts,
> he threatened them with libel.
Note that I start on topic, but am disrupted by personal attacks. This
is because the regulars here are not qualified programmers. Heathfield
has worked on corporate teams in which one goal is to mutually cover
up for inadequacy (and note that there is nothing wrong with this):
Heathfield scored low on an objective test in the related language C+
+. Seebs has told us that on the job he does not actually program, but
finds bugs and sends them on. Seebs, to his credit, also seems to be a
good script kiddie, but with comments like "the 'heap' is a DOS term",
he makes his limitations clear.
Heathfield, Seebs et al. seem to have memorized the standard even as
we learned Latin in high school: a dead language and a set of rules
more reflective of one grammarian's views, and the dead hand of the
Church, than of praxis. Indeed, their not wanting to assign meaning to
void as a pointer is starkly similar to the ways in which grammarians
(who as taxonomists are pre-scientific) tell us we "must" use silly
and non-orthogonal rules such as who/whom.
As to the libel charge. Heathfield made the malicious claim which he
knew to be false that I'd not been accepted by the strictly and
intelligently moderated group comp.risks. I have initiated legal
action on this matter.
spinoza1111
wrote:
I have started technical and meta threads. The technical threads,
which are started first, have been disrupted by Heathfield since 1999,
when he lost control of a popular discussion of programming
professionalism in comp.programming owing to his lack of education. I
have started meta-threads such as "Richard Heathfield's lie" in
egregious cases of abuse, such as claiming that I haven't published in
comp.risks. Heathfield was even called by his butt buddies on that
one.
My topic here is germane. It is the flaws of C, since they are so
serious as to mean that it should not be used.
Meta threads are necessary if people misuse this group for their own
agenda. Heathfield's is to claim a false expertise, as is Seebach, who
appears to use pseudo-professional activities (such as buying his way
on to the standards committee) in place of learning his profession.
spinoza1111
> This group is about building C progreams
> and the C language in general.
>
>
> o linking problems
> o debugging problems
> o makefile problems related to the building of a c program
> o compiling and compiler related questions
>
> the scope of this group are part of a small self proclaimed
> group that thinks it can restrict the scope of this group
> to C89.
>
> they are the principal originators of completely off topic
> conversations here (the endless spinoza111 threads are a proof
> of that).
>
>
Monsieur, whereas I have always started on topic, I also believe that
people have a right to defend their good name. And in such defense I
have generally RETURNED to the topic, for example by posting code that
other posters are too incompetent or cowardly to write, the latter
because they are afraid that they will be mocked for making trivial
errors, by clerks.
spinoza1111
> jacob navia wrote:
> > This group is about building C progreams
>
>
>
> are only two internationally recognised definitions of C - ISO 9899:1990
> and ISO 9899:1999.
>
>
> > o linking problems
> > o debugging problems
> > o makefile problems related to the building of a c program
> > o compiling and compiler related questions
>
> you're arguing that topicality should be widened, well, I agree
> (although we don't necessarily agree about the direction of that
> widening) - but the majority view is against us. Or at least, it was,
> last time anyone bothered to check.
>
> > the scope of this group are part of a small self proclaimed
> > group that thinks it can restrict the scope of this group
> > to C89.
>
> contributors to the group. In a democracy, they win and we lose. That's
> life.
>
> > they are the principal originators of completely off topic
> > conversations here (the endless spinoza111 threads are a proof
> > of that).
>
> off-topic aspects are principally originated byspinoza1111.
>
>
Richard, children and thugs use language like that.
> newsgroup about C, not a personal blog for your compiler. If you want a
> personal blog for your compiler, your Web site would be a good bet.
> Failing that, try comp.compilers.lcc.
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within
spinoza1111
> Richard Heathfield wrote:
>
> > If you look at the endlessspinoza1111threads, you'll see that their
> > off-topic aspects are principally originated byspinoza1111.
People with inferior educations like the claim of off-topic for two
reasons:
(1) It sounds intelligent
(2) It covers up their ignorance
>
> And principally egged on by Richard Heathfield!
You are very close to admitting that Heathfield is the problem person
here. In environments where bullies and enablers can be removed I have
a very good reputation, including wordpress and facebook. I helped to
set courtesy standards by precept and example at Princeton, but I
don't take shit.
>
> --
> Ian Collins
spinoza1111
> On 2010-01-23, Gareth Owen <gwo...@gmail.com> wrote:
>
> > spinoza111. Having said that, Seebs and Richard Heathfield are his
> > facilitators -- more than happy to continually goad, taunt and mock him,
> > even though they *must* know by now that he cannot have his opinions
> > changed by them.
>
> data in a functional way, I plonked him and stopped responding. That woulda
> been weeks ago, I think.
>
You little weasel, you know that I see this shit. Your behavior is
that of the drunk or wasto at the party who turns away from someone
else and loudly insults him to a third party.
What an asshole.
> So I don't think I count as a facilitator now. I tried to argue with him
> for a while, tried to plumb the madness for a while in the hopes that it
> would at least yield interesting ways of being wrong about C, and then
> concluded that the marginal cost of getting an interesting observation from
> arguing with him was too high to justify it.
The translation is you lost the argument.
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
> jacob navia <ja...@nospam.org> writes:
> > This group is about building C progreams
> > and the C language in general.
>
> > This includes (but is not limited to)
>
> > o linking problems
> > o debugging problems
> > o makefile problems related to the building of a c program
> > o compiling and compiler related questions
>
> > Most of the people that argue otherwise and want to restrict
> > the scope of this group are part of a small self proclaimed
> > group that thinks it can restrict the scope of this group
> > to C89.
>
> I disagree, as I've said at length in the past.
>
> > If you look at their recent posting history you will see that
> > they are the principal originators of completely off topic
> > conversations here (the endless spinoza111 threads are a proof
> > of that).
>
> > To avoid clutter I will not answer any of their answers, if any.
>
> At least two regular posters have participated in pointless debates
Translation: "I have a masters degree",
"I have a MASTER'S degree" - Ask Mister Science, Duck's Breath Mystery
Theater
"but it is incomprehensible to me how this guy could know my trade and
so much else besides about art and shit. Therefore, he don't know shit
about my trade, I do, and I must destroy his credibility."
> withspinoza1111, but have stopped doing so, or at least substantially
frank
> On 2010-01-23, Richard Tobin <ric...@cogsci.ed.ac.uk> wrote:
snip
I think a lot of it is a sense of measure. I'm writing a program in
standard C that is getting hung up because I'm using an implementation
and platform that easily trips me on occasion. So it's fundamentally
about C, and because everything *MUST* happen on an implementation and
platform, well the specifics of this little thing that is a bump in the
road to me is not understanding the switches.
If I had said, is "stopping after the preprocessing stage; not running
the compiler proper, whilst the preprocessed source code is sent to
stdout" something that you can do in standard C, is not the answer
emphatically, "yes?"
--
frank
Colonel Harlan Sanders
<spino...@yahoo.com> wrote:
>As to the libel charge. Heathfield made the malicious claim which he
>knew to be false that I'd not been accepted by the strictly and
>intelligently moderated group comp.risks. I have initiated legal
>action on this matter.
No you haven't.
Seebs
> I think a lot of it is a sense of measure. I'm writing a program in
> standard C that is getting hung up because I'm using an implementation
> and platform that easily trips me on occasion. So it's fundamentally
> about C, and because everything *MUST* happen on an implementation and
> platform, well the specifics of this little thing that is a bump in the
> road to me is not understanding the switches.
Sort of. Many of those switches would be the same if you were using
the same toolset to work on, say, FORTRAN (and yes, gcc has a FORTRAN
mode) or C++.
> If I had said, is "stopping after the preprocessing stage; not running
> the compiler proper, whilst the preprocessed source code is sent to
> stdout" something that you can do in standard C, is not the answer
> emphatically, "yes?"
Not really. It's true of most existing systems, in fact, all I know of,
but it's not *required*. If I were to implement a compiler in which
the phases of translation all occurred in memory, and the results of
the "preprocessing" phases were implemented, not actually as pure text,
but as a linked list of structures containing things which had been
turned into tokens, well, that would probably be permitted. Indeed,
there's not strictly a requirement that I actually implement the phases
of translation *AT ALL* -- as long as you can't tell, by looking only
at the final output, that I didn't do them as described.
So that's the thing. Standard C isn't an implementation. It is up
to the implementation how much visibility to offer into its internals;
there's no more guarantee of preprocessed output than there is of
assembly output. (And yes, I've used a compiler which didn't really
have assembly output -- you could get it to generate assembler, but that
would not necessarily yield the same binary code that you would get by
running it normally, because it really worked from a sort of intermediate
representation.)
frank
> frank wrote:
>> Richard Heathfield wrote:
>>> jacob navia wrote:
>
> <snip>
>
>>>> Most of the people that argue otherwise and want to restrict
>>>> the scope of this group are part of a small self proclaimed
>>>> group that thinks it can restrict the scope of this group
>>>> to C89.
>>>
>>> No, most of the people who argue otherwise are the majority of
>>> contributors to the group. In a democracy, they win and we lose.
>>> That's life.
>>
>> I've heard that Heathfield wants to bring back C89, but I've never
>> read it myself in here. Maybe I'm missing these threads. Keith has
>> talked about them. The closest I can come to the motivation for this
>> allegation is that he compiles with -ansi (ten years ago).
>
> The reason you don't remember Richard Heathfield (or any one) trying to
> restrict the group to C89 is that no one has tried to do that. It is
> Jacob miss-representing what other people have said, which is that there
> are still very few C99 implementations, so C89/C90/C95 is more portable,
> and it is useful for people to know when they are restricting portability.
Jacob's got some exotic opinions about his persecutors. What I *do* see
from Richard, time and time again, are specific dates and numbers on
revisions of many standards, especially C's.
>
> A lot of companies use MS VCC for compiling C code, and that does not
> implement C99, so earlier (theoretically obsolete) versions of the C
> standard are still very important. I'm hoping that the new stuff being
> put in to C1x will be enough to kick MS in to moving forward and
> implementing the current standard, which would probably push other
> companies in to supporting it.
Well I don't know how they're figuring on moving forward, but they've
done everything to alienate me as a customer since the early nineties.
The last time I tried to re-ignite that M$ spark, Jack Klein had
promised a free c99 M$ compiler at some link. It's bundled with 800
megs of computer pollution. Sometimes that which is "free" is incurring
costs other than monetary ones.
--
frank
frank
> On 2010-01-24, frank <fr...@example.invalid> wrote:
>> I think a lot of it is a sense of measure. I'm writing a program in
>> standard C that is getting hung up because I'm using an implementation
>> and platform that easily trips me on occasion. So it's fundamentally
>> about C, and because everything *MUST* happen on an implementation and
>> platform, well the specifics of this little thing that is a bump in the
>> road to me is not understanding the switches.
>
> Sort of. Many of those switches would be the same if you were using
> the same toolset to work on, say, FORTRAN (and yes, gcc has a FORTRAN
> mode) or C++.
Really? What's it called?
>
>> If I had said, is "stopping after the preprocessing stage; not running
>> the compiler proper, whilst the preprocessed source code is sent to
>> stdout" something that you can do in standard C, is not the answer
>> emphatically, "yes?"
>
> Not really. It's true of most existing systems, in fact, all I know of,
> but it's not *required*. If I were to implement a compiler in which
> the phases of translation all occurred in memory, and the results of
> the "preprocessing" phases were implemented, not actually as pure text,
> but as a linked list of structures containing things which had been
> turned into tokens, well, that would probably be permitted. Indeed,
> there's not strictly a requirement that I actually implement the phases
> of translation *AT ALL* -- as long as you can't tell, by looking only
> at the final output, that I didn't do them as described.
How does gcc do it if not with C?
--
frank
spinoza1111
Insistence on the truth of a taxonomy ("void is not a pointer") is in
fact prescientific. Clerks, subject to brutal corporate discipline,
reverse enlightenment to a stage before. We can't let them actually
program (let them log on to comp.lang.c and tear at each other
instead, on company time), for they under our hegemony have lost the
ability to think critically, as witness their touching loyalty to an
out of date programming language for losers. Let them instead form
scholastic theories which allow us to continue to rule zee verld.
"So that, in truth, Thou didst Thyself lay the foundation for the
destruction of Thy kingdom, and no one is more to blame for it. Yet
what was offered Thee? There are three powers, three powers alone,
able to conquer and to hold captive for ever the conscience of these
impotent rebels for their happiness those forces are miracle, mystery
and authority."
- Dostoevsky, The Brothers Karamazov
In my book "Build Your Own .Net Language and Compiler" (Edward G.
Nilges, Apress 2004) I show how two different yet equivalent grammars
could have different effects (left associative v right associative),
and this shows that grammars are pre-scientific, like biology before
Darwin (is a fungi a plant or an independent genus?).
The problem is that everything is related to everything else and that,
strictly speaking, nothing is off-topic:
"The time has come," the Walrus said,
"To talk of many things:
Of shoes--and ships--and sealing-wax--
Of cabbages--and kings--
And why the sea is boiling hot--
And whether pigs have wings."
This is especially true in the ethical register:
"It's not my business," Scrooge returned. "It's
enough for a man to understand his own business, and
not to interfere with other people's. Mine occupies
me constantly. Good afternoon, gentlemen!"
In other words, Scrooge rules neat lines around his "business" as do
people here in order as do people here to evade his responsibility to
others (as do people here).
The irrationality of such "topicality" is in the fact that concepts
form a space (far more important than cyberspace). As Kant saw, it is
essential to space that it be possible to voyage from any point in any
one space to any other point.
[Possible that is in principle, which is why we're always fascinated
by devices for intergalactic travel such as wormholes. And, arguably,
the Hubble space telescope gives us this capability in a partial sense
already. Seeing is part of the way to being there.]
This means that using language, a wormhole or pathway can be built
between apparently "unrelated" topics. The most striking example being
that before 1974, underarm deodorant had nothing to do with the South
Pole, but then it was found that its propellants released compounds
which destroyed the ozone layer starting at the South Pole.
However, one IS responsible for constructing and not just
hypothesizing the wormhole, and this is difficult for those who labor,
as do so many here, to either construct or understand a thought of
parse tree depth order > small n. This is why they are so ready to say
"shut up" to a real pro like Navia as Heathfield says like a child.
I would say that C and global warming would be an appropriate topic
here, as long as the discussion started responsibly with content about
C: of course, it is true here that boys who've never grown up because
they got cozy techie jobs which they stab others in the back to keep
don't know what the adverb "responsibly" refers to, for in the
corporation, responsibility is replaced by rule-following.
Or, "C programming and Haiti". Perhaps someone here is maintaining
software designed to create shock waves in the earth as a war-fighting
weapon: some have claimed that a test of such weapon went awry and
destroyed Haiti. Of course, this is unverifiable conspiracy theory, so
another topic would be deconstructing the myth that "black people, who
are bilingual for the most part and thus provably more adaptable and
intelligent, cannot program computers and therefore our plans for
'economic development' in Haiti must force black people, many with
technical and university degrees, to work in clothing sweatshops". It
could easily be demonstrated here that many posters are so incompetent
at their trade ("the 'heap' is a DOS term") that they were hired
because of a white skin. Perhaps C is useful at covering up this fact.
Perhaps the pseudo-science of C (its contradictory claim to be
structured and safe, and low-level) creates or is appreciated by the
same sort of minds who deny evolution or global warming while holding
down techie jobs from which they speak with equal pomposity on their
trade.
Everything is related to everything else. The question is whether one
has either the insight to see this or the ability to put it into
words. Hamlet did:
"No faith, not a iot. But to follow him thether with modestie enough,
& likeliehood to lead it; as thus. Alexander died: Alexander was
buried: Alexander re-turneth into dust; the dust is earth; of earth we
make Lome, and why of that Lome (whereto he was conuer-ted) might they
not stopp a Beere-barrell? Imperiall Caesar, dead and turn'd to clay,
Might stop a hole to keepe the winde away."
Oh, that that earth, which kept the world in awe,
Should patch a Wall, t' expell the winters flaw.
Everything is related to everything else
Nothing is irrevelant to solving Holmes' crime.
The small mind protests it wants to be safe
His manager says, we have not the time.
[And for aeons in corporations they never had time.]
The great mind sees all things in a flower
The great mind finds in weakness its power.
Like water it flows where it can and it will
Ignoring the difference between dale and high hill.
Betcha didn't know I was a poet
And it probably burns your ass
That you labor long and wearily your trade so ya know it
Whilst I master your trade and at high speed I you pass.
Betcha didn't know I was a poet
Probably thought I was a jag
But I bet I can make a rhyme for "poet" and not blow it
Dareya try it if yer not "on the rag".
spinoza1111
> Seebs wrote:
That is why Richard Heathfield should be ejected or ostracized for
saying "shut up" to Navia apparently because lcc-win is not The Great
God C. Working C programmers need to know, when maintaining code that
does pointer arithmetic on voids, that GCC allows this, so they don't
shit their pants and unnecessarily rewrite the code when they have
GCC.
Indeed, I now wonder whether Heathfield et al. might use "standards"
to create hourly business by doing unnecessary rewrites. Could they be
so unethical? Nawwww....
spinoza1111
> On Sat, 23 Jan 2010 19:48:42 -0800 (PST),spinoza1111
>
> >As to the libel charge. Heathfield made the malicious claim which he
> >knew to be false that I'd not been accepted by the strictly and
> >intelligently moderated group comp.risks. I have initiated legal
> >action on this matter.
>
> No you haven't.
The Colonel knows all.
The Colonel stands tall.
Like his Daddy down in Tennessee
The Colonel knows you and the Colonel knows me.
Whereas cross dressing as Dorothy I pull the shade
And lo we find Homunculus
A pimply twerp posting nonsensical twaddle
Who only gets up, to the break room to waddle.
Seebs
>> Sort of. Many of those switches would be the same if you were using
>> the same toolset to work on, say, FORTRAN (and yes, gcc has a FORTRAN
>> mode) or C++.
> Really? What's it called?
There's a g77.
> How does gcc do it if not with C?
It's not that it's done with or without C. You could, in standard C,
write a "preprocessor". My point is that there's no requirement that
a compiler be implemented that way; it doesn't have to have a separate
preprocessor.
Kaz Kylheku
> On 2010-01-24, frank <fr...@example.invalid> wrote:
>> Seebs wrote:
>>> Sort of. Many of those switches would be the same if you were using
>>> the same toolset to work on, say, FORTRAN (and yes, gcc has a FORTRAN
>>> mode) or C++.
>
>> Really? What's it called?
>
> There's a g77.
>
>> How does gcc do it if not with C?
>
> It's not that it's done with or without C. You could, in standard C,
> write a "preprocessor". My point is that there's no requirement that
> a compiler be implemented that way; it doesn't have to have a separate
> preprocessor.
The GNU C compiler does not in fact have a separate preprocessor.
It does ship with such a utility because people need it; but
it's not actually used.
C preprocessing in GCC is done by a library (libcpp) linked
right into the compiler, which returns tokens, which are data
structures, and not raw text.
I know this because I've had to debug obscure issues with ccache.
ccache is a tool that intercepts preprocessed program text as text
during compilation, and then conditionally feeds that text
back to the compiler (if it doesn't find a hit in its cache).
Differences can show up between just running the compiler on
a translation unit, and running the compiler such that the pp-tokens
are converted to text, and then running the compiler on that text.
steve
> On 2010-01-24, frank <fr...@example.invalid> wrote:
>
> > Seebs wrote:
> >> Sort of. Many of those switches would be the same if you were using
> >> the same toolset to work on, say, FORTRAN (and yes, gcc has a FORTRAN
> >> mode) or C++.
> > Really? What's it called?
>
> There's a g77.
g77 was dropped from GCC nearly 5 years ago. The Fortran
compiler in GCC is gfortran. BTW, the proper name of the
language is Fortran not FORTRAN. See the Fortran 95 Standard
or newer for the proper spelling of the language.
Oh, and yes, the preprocessor options are the same.
--
steve
spinoza1111
Which is true, but too convenient for people who know very little
about compilers, because they've never written one. In the
bureaucratic sense the demiurge is to create an established Church out
of any real advance in human enlightenment (whether the Sermon on the
Mount or the third law of thermodynamics) lest further advance destroy
the careers of the priests. What's fascinating is this Scholastic
approach to C, which resembles the way in which the "Forty Year Old
Virgin" in the eponymous movie talks about sex:
"You know how when you grab a woman's breast... it feels like... a bag
of sand."
(The "heap" is a DOS term...it feels like a bag of sand).
"I dated this girl for a while... she was really a... nasty freak. She
just loved to... get down with... sex all the time. It was like...
anytime of day... she was like, 'Yeah, let's go! I'm so nasty!'" And
I'd be nailing her and she'd be like, 'Oh, you're nailing me! cool!'"
(The stack is not in the standard. I was in the sack with this stack,
and it screamed, "give it to me Seebie".)
> to the implementation how much visibility to offer into its internals;
> there's no more guarantee of preprocessed output than there is of
> assembly output. (And yes, I've used a compiler which didn't really
> have assembly output -- you could get it to generate assembler, but that
> would not necessarily yield the same binary code that you would get by
> running it normally, because it really worked from a sort of intermediate
> representation.)
>
> -s
> --
spinoza1111
Indeed, fantasizing onanistically about what compilers do is a common
trope in the break room where we go around the prickly pear at four
o'clock in the morning, trying to find bugs because the client has
told us we must find ten or else (or some shit assignment like that).
This is why actual people who have written compilers find here that
the shits redefine their work as anything but, using absurd litmus
tests (when in fact to compile to interpretive language is
compilation). They live in a world that they must perforce mythologize
for their sanity, constructed by giants of old such as Brian
Kernighan.
"Actually writing a compiler" is lese-majeste although compiling
special purpose languages is an excellent way of solving real
problems. Instead, one is expected to find the local computing thug
and flatter him.
T. S. Eliot
Animula
Issues from the hand of God, the simple soul,
To a flat world of changing lights and noise,
To light, dark, dry, damp, chilly or warm,
Moving between the legs of tables and of chairs
Rising or falling,
Grasping at kisses and toys,
Advancing boldly, sudden to take alarm,
Retreating to the corner of arm and knee,
Eager to be reassured, taking pleasure
In the fragrant brilliance of the Christmas tree
Pleasure in the wind, the sunlight and the sea'
Studies the sunlit pattern on the floor.
And running stays around a silver tag:
Confounds the actual and the fanciful,
Content with playing cards and kings and queens,
What the fairies do and what the servants say.
The heavy burden of the growing soul
Perplexes and offends more, day by day,
Week by week, offends and perplexes more.
With the imperatives of "so it seems"
And may and may not, desire and control.
The pain of living and the drug of dreams
Curl up the small soul in the window seat
Behind the Encyclopaedia Britannica.
Issues from the hand of time, the simple soul,
Irresolute and sefish, misshapen, lame
Unable to fare forward or retreat,
Fearing the warm reality, the offered good,
Denying the importunity of the blot,
Shadow of its own shadow, spectre of its own gloom,
Leaving disordered papers in a dusty room;
Living first in silence after the viaticum,
Pray for Guiterriez, avid of speed and power
For Boudin, blown to pieces,
For this one, who made a great fortune
And that one who went his own way.
Pray for Floret by the boorhound slain between the yew trees,
Pray for us now and at the hour of our birth.
spinoza1111
> jacob navia wrote:
>
>
>
> are only two internationally recognised definitions of C - ISO 9899:1990
> and ISO 9899:1999.
You completely fail to understand either formal or human language,
dickhead.
Formal language shows us that the union of languages is also a
language. Your silly view is destructive because it means that most
programmers ordinarily thought of as coding in "C" program in a
nameless language, since you've destroyed the name.
This is the same form of half-educated intolerance in which the
fundamentalist Jew claims that the Reform Jew is "not a jew", the
fundamentalist Protestant says "Catholics aren't Christians", and the
Shi'ite Moslem denies that his Sunni brothers are Moslems.
The linguistics of human language show us that it is folly to say that
a language can be "defined" from on high.
>
> > This includes (but is not limited to)
>
> > o linking problems
> > o debugging problems
> > o makefile problems related to the building of a c program
> > o compiling and compiler related questions
>
> That's a view, but I think you'll find it's not a majority view. If
> you're arguing that topicality should be widened, well, I agree
> (although we don't necessarily agree about the direction of that
> widening) - but the majority view is against us. Or at least, it was,
> last time anyone bothered to check.
>
> > Most of the people that argue otherwise and want to restrict
> > the scope of this group are part of a small self proclaimed
> > group that thinks it can restrict the scope of this group
> > to C89.
>
> No, most of the people who argue otherwise are the majority of
> contributors to the group. In a democracy, they win and we lose. That's
> life.
>
> > If you look at their recent posting history you will see that
> > they are the principal originators of completely off topic
> > conversations here (the endless spinoza111 threads are a proof
> > of that).
>
> If you look at the endlessspinoza1111threads, you'll see that their
> off-topic aspects are principally originated byspinoza1111.
That is simply not the case. Most recently, I posted code which
demonstrated that C Sharp is only ten percent slower, and you and
others disrupted this thread because you just can't figure out how
someone mastered your trade and so much else besides (such as the
ability to form complete sentences of parse depth > small n). I fought
back.
>
> > To avoid clutter I will not answer any of their answers, if any.
>
> Can you also avoid clutter by shutting up about lcc-win32? This is a
> newsgroup about C, not a personal blog for your compiler. If you want a
> personal blog for your compiler, your Web site would be a good bet.
> Failing that, try comp.compilers.lcc.
Navia is one of the few individuals here to be a serious coder, and
you can't stand that, since you're some sort of managerial creep.
spinoza1111
> > off-topic aspects are principally originated byspinoza1111.
>
That is correct, if to be "egged on" is to refuse to back down when
attacked.
In an early case, I used an invariant expression in a C for loop in
2003, and Richard Heathfield, in a jealous rage since I'd created a
well-received thread on programming professionalism in 2003 (a thread
which got me invited to a panel discussion with Cass Sunstein and Mike
Godwin at Princeton University Press), enabled a cybernetic mob attack
which generalized from this single data point that I was
"incompetent".
I conceded that I'd neglected the fact that unlike, and nonorthogonal
to, other languages, the C for repeatedly evaluates the limit
condition because its "test" is an expression and not a limit value. I
mentioned that I'd not coded in C since 1992 since at that time I
found it inadequate for large systems because it could not do objects,
and I showed how the for loop was incompetently designed.
Because Richard Heathfield labors to create data points that support
his stupid ideas, he uses packrat methods, and instead of dialoging
with the people he bullies, he repeats words like "stupid" without
justification and in a manner that begs the question. This is how the
Nazis used media: Godwin's convergence in his case is justified by his
behavior, which is characteristic of the half-educated white collar
technical class that supported Hitler's election.
>
> --
> Ian Collins
spinoza1111
> On Jan 23, 4:41 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > jacob navia wrote:
> > > This group is about building C progreams
Yes it is. The problem with overdefining "focus" is that since
concepts form a space, and space is by definition connected actually
or in principle, any partition is strictly administrative and thus
potentially oppressive in the sense that it stops thinking, and
thinking is better than following administrative rules.
For example, one of the most ground-breaking books in computer science
was entitled "The Psychology of Computer Programming". Had there been
a usenet in 1970, had Weinberg tried to air his ideas in
comp.programming (not being justified at all in putting them in
comp.lang.c, this clear lack of justification showing we can be
rational while not being overfocused), Heathfield would have told him
to get lost.
Another example was how a twerpish and narrow minded little coder at
my 1976 bachelor party, looking at my computer books, laughed at a
book...its name was "The Art of Computer Programming".
Besides, as Heathfield's disgusting behavior in this thread, telling
you to shut up, makes clear, hatred and incivility are always on topic
in this shithole.
Flash Gordon
Should people refer to the C standard released some time between 1987
and 1994 instead, when they know the year it was released? Should people
avoid using the correct number if they know it, when using the correct
number means people can easily track down information about it?
>> A lot of companies use MS VCC for compiling C code, and that does not
>> implement C99, so earlier (theoretically obsolete) versions of the C
>> standard are still very important. I'm hoping that the new stuff being
>> put in to C1x will be enough to kick MS in to moving forward and
>> implementing the current standard, which would probably push other
>> companies in to supporting it.
>
> Well I don't know how they're figuring on moving forward, but they've
> done everything to alienate me as a customer since the early nineties.
>
> The last time I tried to re-ignite that M$ spark, Jack Klein had
> promised a free c99 M$ compiler at some link. It's bundled with 800
> megs of computer pollution. Sometimes that which is "free" is incurring
> costs other than monetary ones.
It's C89 not C99, and MS don't charge for it and the license is fairly
relaxed on what you can do. It is also pretty good as a C90 compiler.
That it is too big for you with all the bits it comes with is another
matter.
--
Flash Gordon
Phil Carmody
> Ian Collins wrote:
>> Richard Heathfield wrote:
>>>
>>> If you look at the endless spinoza1111 threads, you'll see that
>>> their off-topic aspects are principally originated by spinoza1111.
>>
>
> I am, perhaps you might respond as I have responded in the past.
No right-thinking individual has changed their attitute towards
you in a negative way from anything that Nilges has come out with.
The only change might be towards sympathy, as he's clearly a bit
of a stalker as well as a kook.
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Phil Carmody
> From: "Peter J. Holzer" <hjp-usen...@hjp.at>
> For germans, hanging on to even high german is ridiculous.
Erm, are you sure he's a German?
Phil Carmody
> On Sat, 23 Jan 2010 13:27:46 +0000 (UTC), gaz...@shell.xmission.com
> (Kenny McCormack) wrote:
>
>>Point out one thread started by Mr. Nilges.
>>
>>Thank you.
>
>
> Newsgroups: comp.lang.c
> Subject: C as deep blasphemy
> Date: Wed, 30 Dec 2009 02:56:54 -0800 (PST)
>
> From: spinoza1111 <spino...@yahoo.com>
> Newsgroups: comp.lang.c
> Subject: Comparision of C Sharp and C performance
> Date: Sun, 27 Dec 2009 06:36:54 -0800 (PST)
>
> From: spinoza1111 <spino...@yahoo.com>
> Newsgroups: comp.lang.c
> Subject: C is NOT significantly more efficient than C Sharp
> Date: Sun, 27 Dec 2009 02:50:15 -0800 (PST)
>
> From: spinoza1111 <spino...@yahoo.com>
> Newsgroups: comp.lang.c
> Subject: Peter Seebach's behavior as "moderator" of comp.lang.C
> Date: Fri, 25 Dec 2009 04:04:15 -0800 (PST)
>
> From: spinoza1111 <spino...@yahoo.com>
> Newsgroups: comp.lang.c,comp.programming
> Subject: Richard Heathfield's lie
> Date: Thu, 24 Dec 2009 09:14:51 -0800 (PST)
>
> etc, etc...
>
> Of course, the last time someone claimed they couldn't find his posts,
> he threatened them with libel.
Thank you for being so keen to feed the troll, I'm sure he
got a real kick out of you doing precicely what he asked for.
Nick Keighley
> jacob navia wrote:
> > This group is about building C progreams
>
>
> > and the C language in general.
>
> I would say it's currently about the C language in particular. And there
> are only two internationally recognised definitions of C - ISO 9899:1990
> and ISO 9899:1999.
and the K&R de-facto standard? People do seem to come across it from
time to time. Or is that covered by C89?
spinoza1111
wrote:> > On Sat, 23 Jan 2010 13:27:46 +0000 (UTC), gaze...@shell.xmission.com
> > (Kenny McCormack) wrote:
>
> >>Point out one thread started by Mr. Nilges.
>
> >>Thank you.
>
> > Newsgroups: comp.lang.c
> > Subject: C as deep blasphemy
> > Date: Wed, 30 Dec 2009 02:56:54 -0800 (PST)
>
> > Newsgroups: comp.lang.c
> > Subject: Comparision of C Sharp and C performance
> > Date: Sun, 27 Dec 2009 06:36:54 -0800 (PST)
>
> > Newsgroups: comp.lang.c
> > Subject: C is NOT significantly more efficient than C Sharp
> > Date: Sun, 27 Dec 2009 02:50:15 -0800 (PST)
>
> > Newsgroups: comp.lang.c
> > Subject: Peter Seebach's behavior as "moderator" of comp.lang.C
> > Date: Fri, 25 Dec 2009 04:04:15 -0800 (PST)
>
> > Newsgroups: comp.lang.c,comp.programming
> > Subject: Richard Heathfield's lie
> > Date: Thu, 24 Dec 2009 09:14:51 -0800 (PST)
>
> > etc, etc...
>
> > Of course, the last time someone claimed they couldn't find his posts,
> > he threatened them with libel.
>
> Thank you for being so keen to feed the troll, I'm sure he
> got a real kick out of you doing precicely what he asked for.
I am not a troll. A troll is someone who posts in bad faith in order
to get a rise out of someone, and I mean what I say on all topics.
"Troll" is a nordic-racist word meant to refer to peoples pushed aside
by invaders in the Dark Ages. In modern American discourse, it
appeared in 1986 to mean homeless person, and it was used by wealthy
homeowners of Santa Cruz in a campaign to "cleanse" Santa Cruz of
homeless people. It is therefore an offensive term.
However, I do find that people are indeed addicted to making stupid
comments about my remarks and cannot resist. They have the mob's
fascination with a person who refuses to join the mob.
Nick Keighley
> Flash Gordon wrote:
> > frank wrote:
> >> Richard Heathfield wrote:
> >>> jacob navia wrote:
> >>>> Most of the people that argue otherwise and want to restrict
> >>>> the scope of this group are part of a small self proclaimed
> >>>> group that thinks it can restrict the scope of this group
> >>>> to C89.
this is untrue.
<snip>
> >> I've heard that Heathfield wants to bring back C89, but I've never
> >> read it myself in here.
that's because it isn't true.
> >> Maybe I'm missing these threads. Keith has
> >> talked about them. The closest I can come to the motivation for this
> >> allegation is that he compiles with -ansi (ten years ago).
Richard uses C89 as he believes it is more portable than the less
widely implemented C99. I tend agree.
OTOH Richard doesn't try and restrict anyone else from using C99. That
he does is pure invention.
> > The reason you don't remember Richard Heathfield (or any one) trying to
> > restrict the group to C89 is that no one has tried to do that. It is
> > Jacob miss-representing what other people have said, which is that there
> > are still very few C99 implementations, so C89/C90/C95 is more portable,
> > and it is useful for people to know when they are restricting portability.
>
> Jacob's got some exotic opinions about his persecutors.
"exotic"!
> What I *do* see
> from Richard, time and time again, are specific dates and numbers on
> revisions of many standards, especially C's.
He often quotes the ISO (International Organisation for
Standardisation) standard identities for the 89 (actually I think its
1990 for the ISO standard- the ANSI standard was 1989) and 99
standard.
> > A lot of companies use MS VCC for compiling C code, and that does not
> > implement C99, so earlier (theoretically obsolete) versions of the C
> > standard are still very important.
there's a sort of boot strap problem. People use C89 because it's more
portable. Hence implementors feel less pressure to implement C99.
Hence C89 is more portable...
It's 2010; if C99 hasn't taken the world by storm by now it never
will.
> > I'm hoping that the new stuff being
> > put in to C1x will be enough to kick MS in to moving forward and
> > implementing the current standard, which would probably push other
> > companies in to supporting it.
what's in C1x? There was little in C99 that appealed to me (bool I
think). It's unlikely adding to the pile will help. Thread support
maybe?
> Well I don't know how they're figuring on moving forward, but they've
> done everything to alienate me as a customer since the early nineties.
>
> The last time I tried to re-ignite that M$ spark, Jack Klein had
> promised a free c99 M$ compiler at some link. It's bundled with 800
> megs of computer pollution. Sometimes that which is "free" is incurring
> costs other than monetary ones.
I've no idea what this is about. Does Jack Klein have some influence
over MS?
Nick Keighley
> Actually, once I figured out that he was essentially incapable of processing
> data in a functional way [...]
perhaps he's procedural or object oriented?
Flash Gordon
> On 24 Jan, 04:52, frank <fr...@example.invalid> wrote:
>> Flash Gordon wrote:
<snip>
>>> I'm hoping that the new stuff being
>>> put in to C1x will be enough to kick MS in to moving forward and
>>> implementing the current standard, which would probably push other
>>> companies in to supporting it.
>
> what's in C1x? There was little in C99 that appealed to me (bool I
> think). It's unlikely adding to the pile will help. Thread support
> maybe?
<snip>
As a matter of fact... yes, that is one of the things they are working
on. It's also something I think a lot of C users would like, since it
can be painful doing cross-platform threaded applications at the moment.
For more information, have a look at the current drafts and documents,
and also ask over in comp.std.c
--
Flash Gordon
Keith Thompson
No, it's not covered by C89; as you know, K&R C (i.e., the language
described by K&R1) and C89 are quite different. I've argued before
that K&R C is entirely topical here. I don't recall anyone seriously
disagreeing with that. I'm not sure why Richard left it out.
Richard Heathfield
I can't bring to mind any current contributor (or indeed past
contributor) who has ever mentioned considering K&R C to be off-topic.
When this group was created, there weren't any ISO C standards, so (the
many-flavoured) K&R C was basically all there was. People who refer to
its topicality here generally refer to "historical reasons" - of course,
as you say, it does still crop up in here from time to time, apparently
in currently-maintained code, so it's not *just* historical reasons.
Richard Heathfield
> Nick Keighley <nick_keigh...@hotmail.com> writes:
>> On 23 Jan, 08:41, Richard Heathfield <r...@see.sig.invalid> wrote:
>>> jacob navia wrote:
>>>> This group is about building C progreams
>>> Perhaps it should be, but it currently isn't.
>>>
>>>> and the C language in general.
>>> I would say it's currently about the C language in particular. And there
>>> are only two internationally recognised definitions of C - ISO 9899:1990
>>> and ISO 9899:1999.
>> and the K&R de-facto standard? People do seem to come across it from
>> time to time. Or is that covered by C89?
>
> No, it's not covered by C89; as you know, K&R C (i.e., the language
> described by K&R1) and C89 are quite different. I've argued before
> that K&R C is entirely topical here. I don't recall anyone seriously
> disagreeing with that. I'm not sure why Richard left it out.
Not because it isn't topical, that's for sure. But I didn't think I
could get away with claiming that K&R C is a definition of the language
that is recognised internationally in the same way that ISO C is. On
reflection, I suppose I could have made a case for C89, and presumably
therefore also C90, recognising K&R C (which it calls "the de facto C
programming language standard") within the (admittedly non-normative)
foreword.
lawrenc...@siemens.com
>
> If I had said, is "stopping after the preprocessing stage; not running
> the compiler proper, whilst the preprocessed source code is sent to
> stdout" something that you can do in standard C, is not the answer
> emphatically, "yes?"
On the contrary, the answer is emphatically "no". In standard C, the
output of the preprocessor is a sequence of *tokens*, not text. And
although it is possible to generate C program text that closely
approximates that sequence of tokens, it is not possible to do so
perfectly in all cases. For example, given the definition:
#define A() x
the sequence:
A()y
results is the token x immediately followed by the token y with no
intervening whitespace. Representing that as text either requires
adding whitespace that should not be there:
x y
or allowing the two tokens to be conflated into one:
xy
--
Larry Jones
It's either spectacular, unbelievable success, or crushing, hopeless
defeat! There is no middle ground! -- Calvin
frank
> frank <fr...@example.invalid> wrote:
>> If I had said, is "stopping after the preprocessing stage; not running
>> the compiler proper, whilst the preprocessed source code is sent to
>> stdout" something that you can do in standard C, is not the answer
>> emphatically, "yes?"
>
> On the contrary, the answer is emphatically "no". In standard C, the
> output of the preprocessor is a sequence of *tokens*, not text. And
> although it is possible to generate C program text that closely
> approximates that sequence of tokens, it is not possible to do so
> perfectly in all cases. For example, given the definition:
>
> #define A() x
>
> the sequence:
>
> A()y
>
> results is the token x immediately followed by the token y with no
> intervening whitespace. Representing that as text either requires
> adding whitespace that should not be there:
>
> x y
>
> or allowing the two tokens to be conflated into one:
>
> xy
Aha, is there a way to look at those tokens such that it is readable to
ordinary mortals?
--
frank
frank
> frank <fr...@example.invalid> writes:
>> From: "Peter J. Holzer" <hjp-usen...@hjp.at>
>> For germans, hanging on to even high german is ridiculous.
>
> Erm, are you sure he's a German?
>
> Phil
No. He knows it tho' and probably other languages. I thought it was an
interesting exchange because he made so much sense with his point while
Chuck used fallacy in his counterpoint.
--
frank
Richard Heathfield
> lawrenc...@siemens.com wrote:
<snip>
>> For example, given the definition:
>>
>> #define A() x
>>
>> the sequence:
>>
>> A()y
>>
>> results is the token x immediately followed by the token y with no
>> intervening whitespace. Representing that as text either requires
>> adding whitespace that should not be there:
>>
>> x y
>>
>> or allowing the two tokens to be conflated into one:
>>
>> xy
>
> Aha, is there a way to look at those tokens such that it is readable to
> ordinary mortals?
One obvious way would be to delimit each token, e.g. using square
brackets: [x][y]
(Then, of course, you'd have the problem of how to present literal
brackets. But you could use an escape character or something.)
frank
Flash, are you involved in the gcc project?
--
frank
frank
> Nick Keighley wrote:
>> On 23 Jan, 08:41, Richard Heathfield <r...@see.sig.invalid> wrote:
>>> jacob navia wrote:
>>>> This group is about building C progreams
>>> Perhaps it should be, but it currently isn't.
>>>
>>>> and the C language in general.
>>> I would say it's currently about the C language in particular. And there
>>> are only two internationally recognised definitions of C - ISO 9899:1990
>>> and ISO 9899:1999.
>>
>> and the K&R de-facto standard? People do seem to come across it from
>> time to time. Or is that covered by C89?
>
> I can't bring to mind any current contributor (or indeed past
> contributor) who has ever mentioned considering K&R C to be off-topic.
> When this group was created, there weren't any ISO C standards, so (the
> many-flavoured) K&R C was basically all there was. People who refer to
> its topicality here generally refer to "historical reasons" - of course,
> as you say, it does still crop up in here from time to time, apparently
> in currently-maintained code, so it's not *just* historical reasons.
>
Right. In some ways it's like c.l.fortran in that occasionally people
really do have to work with something in that awful old fixed-form f77
source.
But they have a big tent philosophy, and it makes it a more interesting
place. Fortran is freely mixed with Ruby, C, and Matlab. Richard Maine
always talks about the (Fortran) standard. As the central figure in
c.l.f., however, he is always willing to talk about all those areas
where the fortran rubber hits the road, *and* no one begrudges others
when they do the same.
I'm not suggesting a blanket detente. For example, threads in C++ bore
me enough to say "down the hallway, please."
--
frank
spinoza1111
This morning's group of posters have collectively been exercising self-
control and not responding to me. I support this, and I won't enter
this (informal) subthread. I invite constructive and on-topic
criticism and comments on C and its relationship to other topics
including its deficiencies, and I support this unusual level of self-
control.
spinoza1111
These posters in this discussion are off-topic with respect to Jacob's
thread topic, which is "what is on topic here", nonetheless are
exercising admirable self-control and discussing, if not the thread
topic, the newsgroup topic, and notice how this amnesties them from
any infraction.
In particular, Richard Heathfield is behaving himself in an
unprecedented way.
Keep up the good work, fellas.
frank
> On 24 Jan, 04:52, frank <fr...@example.invalid> wrote:
> Richard uses C89 as he believes it is more portable than the less
> widely implemented C99. I tend agree.
He might have his compiler switches biased toward C90, but his source
listings never fail on me because of language differences between those
standards.
> there's a sort of boot strap problem. People use C89 because it's more
> portable. Hence implementors feel less pressure to implement C99.
> Hence C89 is more portable...
>
> It's 2010; if C99 hasn't taken the world by storm by now it never
> will.
I think the fallacy here is thinking that if something doesn't catch on
right away, it doesn't catch on. Peoples' hopes for standards and
compilers are bigger than realities. You might think the situation
sucks for C in particular, but I don't think so.
>> The last time I tried to re-ignite that M$ spark, Jack Klein had
>> promised a free c99 M$ compiler at some link. It's bundled with 800
>> megs of computer pollution. Sometimes that which is "free" is incurring
>> costs other than monetary ones.
>
> I've no idea what this is about. Does Jack Klein have some influence
> over MS?
He just posted the link and is well known.
--
frank
Phil Carmody
> Keith Thompson wrote:
>> Nick Keighley <nick_keigh...@hotmail.com> writes:
>>> On 23 Jan, 08:41, Richard Heathfield <r...@see.sig.invalid> wrote:
>>>> jacob navia wrote:
>>>>> This group is about building C progreams
>>>> Perhaps it should be, but it currently isn't.
>>>>
>>>>> and the C language in general.
>>>> I would say it's currently about the C language in particular. And there
>>>> are only two internationally recognised definitions of C - ISO 9899:1990
>>>> and ISO 9899:1999.
>>> and the K&R de-facto standard? People do seem to come across it from
>>> time to time. Or is that covered by C89?
>>
>> No, it's not covered by C89; as you know, K&R C (i.e., the language
>> described by K&R1) and C89 are quite different. I've argued before
>> that K&R C is entirely topical here. I don't recall anyone seriously
>> disagreeing with that. I'm not sure why Richard left it out.
>
> Not because it isn't topical, that's for sure. But I didn't think I
> could get away with claiming that K&R C is a definition of the
> language that is recognised internationally in the same way that ISO C
> is.
Absolutely. One is a paedagogical definitive text from a source that
garners respect almost universally, while the other comes from a body
who in places reaches decisions through monopoly-driven ballot-stuffing
sock-puppetry.
;-)
Nick Keighley
> Nick Keighley wrote:
> > On 24 Jan, 04:52, frank <fr...@example.invalid> wrote:
> >> Flash Gordon wrote:
>
> >>> I'm hoping that the new stuff being
> >>> put in to C1x will be enough to kick MS in to moving forward and
> >>> implementing the current standard, which would probably push other
> >>> companies in to supporting it.
>
> > what's in C1x? There was little in C99 that appealed to me (bool I
> > think). It's unlikely adding to the pile will help. Thread support
> > maybe?
>
> on.
that's why I suggested it. i'd heard rumours. Hoiw does it match up
with what C++ is doing are have they now just diverged too far?
Nick Keighley
> Nick Keighley wrote:
> > On 24 Jan, 04:52, frank <fr...@example.invalid> wrote:
> > Richard [Heathfield] uses C89 as he believes it is more portable than the less
> > widely implemented C99. I tend [to] agree.
>
> He might have his compiler switches biased toward C90, but his source
> listings never fail on me because of language differences between those
> standards.
so he writes code that will compile on either? The point he doesn't
use C99 features.
> > there's a sort of boot strap problem. People use C89 because it's more
> > portable. Hence implementors feel less pressure to implement C99.
> > Hence C89 is more portable...
>
> > It's 2010; if C99 hasn't taken the world by storm by now it never
> > will.
>
> I think the fallacy here is thinking that if something doesn't catch on
> right away, it doesn't catch on.
the fallacy here, is suggesting that over a decade is "right away".
The standard is supposed to be reviewed with a shorter cycle time than
that.
> Peoples' hopes for standards and
> compilers are bigger than realities. You might think the situation
> sucks for C in particular, but I don't think so.
I don't know what this means. I think the effective rejection of C99
is a bit sad but it's happened.
<snip incomprehensible stuff>
Richard Tobin
Jens Thoms Toerring <j...@toerring.de> wrote:
>> Comp.lang.c is for discussion of the C language, including common
>> implementations and related tools (especially those on unix, where it
>> originated).
>Could you be so kind to define this somewhat more precisely?
I thought it would be obvious that I wasn't proposing that as a real
charter for the newsgroup. Rather I was doing what so many others
have done in recent years, asserting my interests as if they were the
definition of the newsgroup.
I don't see any hope of getting consensus on what comp.lang.c should
be. I generally avoid the topicality discussions, but from time to
time I like to state my preferences to ensure that the argument
doesn't go by default.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Heathfield
> On 25 Jan, 03:31, frank <fr...@example.invalid> wrote:
>> Nick Keighley wrote:
>>> On 24 Jan, 04:52, frank <fr...@example.invalid> wrote:
>
>
>>> Richard [Heathfield] uses C89 as he believes it is more portable than the less
>>> widely implemented C99. I tend [to] agree.
>> He might have his compiler switches biased toward C90, but his source
>> listings never fail on me because of language differences between those
>> standards.
>
> so he writes code that will compile on either?
Yes. Until C99 becomes universally (or at least near-universally)
adopted, it makes sense (to those for whom portability is a high
priority) to ensure that one's code still works under C90 rules - but it
/also/ makes sense to ensure that one doesn't use C90 features that
break under C99. So that's what I do.
> The point he doesn't use C99 features.
Except when they are also C90 features. :-)
Of course, I am deliberately over-interpreting you. You actually mean
what we might express as:
int rjh_will_reject(feature f)
{
return !C90(f) || !C99(f) || !same_semantics(f);
}
Or, slightly more simply:
int rjh_will_accept(feature f)
{
return C90(f) && C99(f) && same_semantics(f);
}
<snip>
>>> It's 2010; if C99 hasn't taken the world by storm by now it never
>>> will.
>> I think the fallacy here is thinking that if something doesn't catch on
>> right away, it doesn't catch on.
>
> the fallacy here, is suggesting that over a decade is "right away".
> The standard is supposed to be reviewed with a shorter cycle time than
> that.
Yes. I am guessing that the shift from C0x to C1x suggests that they've
dropped a decade either in the hope that C99 will catch on in the
interim, or in the recognition that it won't, so that a big
(decade-long!) re-think is required.
>> Peoples' hopes for standards and
>> compilers are bigger than realities. You might think the situation
>> sucks for C in particular, but I don't think so.
>
> I don't know what this means. I think the effective rejection of C99
> is a bit sad but it's happened.
In a sense, it's a curate's egg - good in parts. The problem is that
different implementors admire different parts.
Ersek, Laszlo
> one doesn't use C90 features that break under C99
Could you please suggest a summary of those features? (Besides
"restrict".) I guess paragraph 5 of the ISO/IEC 9899:1999 (E) Foreword
could serve as a basis, but if there's anything pre-cooked, I'd like to
start with that.
>>>> It's 2010; if C99 hasn't taken the world by storm by now it never
>>>> will.
>>> I think the fallacy here is thinking that if something doesn't catch on
>>> right away, it doesn't catch on.
>>
>> the fallacy here, is suggesting that over a decade is "right away".
>> The standard is supposed to be reviewed with a shorter cycle time than
>> that.
>
> Yes. I am guessing that the shift from C0x to C1x suggests that they've
> dropped a decade either in the hope that C99 will catch on in the
> interim, or in the recognition that it won't, so that a big
> (decade-long!) re-think is required.
I don't avoid coding for C99 because I "reject" it -- I simply have no
choice than code for C90 if I want my code to compile *wherever* I go
(and I've never even coded for a non-hosted/embedded environment yet).
I've recently got some heat for not using strerror_r() or so --
strerror_r() was standardized in 2003 (2002?) in SUSv3, and I coded for
SUSv2 (first SUS with threads, released in 1998 (1997?)). My decision to
stick to the oldest SUS standard with threads proved justified elsewhere
[0]. What's more, if I wish for a fleeting chance to compile my stuff on
the OpenVMS machine mentioned before, I have to constrain myself to
SUSv1 (released in 1994/1995 I guess).
Isn't there an English term for when the first version is so great that
people mostly see no reason to upgrade afterwards?
Thanks,
lacos
Nick Keighley
On 25 Jan, 13:43, Richard Heathfield <r...@see.sig.invalid> wrote:
> Nick Keighley wrote:
> > On 25 Jan, 03:31, frank <fr...@example.invalid> wrote:
> >> Nick Keighley wrote:
> >>> On 24 Jan, 04:52, frank <fr...@example.invalid> wrote:
<snip>
> >>> It's 2010; if C99 hasn't taken the world by storm by now it never
> >>> will.
>
> >> I think the fallacy here is thinking that if something doesn't catch on
> >> right away, it doesn't catch on.
>
> > the fallacy here, is suggesting that over a decade is "right away".
> > The standard is supposed to be reviewed with a shorter cycle time than
> > that.
>
> Yes. I am guessing that the shift from C0x to C1x suggests that they've
> dropped a decade either in the hope that C99 will catch on in the
> interim, or in the recognition that it won't, so that a big
> (decade-long!) re-think is required.
The scheme people have had a similar blood bath. Scheme is supposed
(so the original schemers thought) to be a very minimalist Lisp
dialect. The C of lisp-like languages...
"Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary."
All features had to be accepted by unaminous agreement of the
committee.
Some features never got agreement (a module concept like #include).
"Modern" features didn't get added.
For R6RS (the 6th revision) they dropped the unaminous agreement
clause. The standard exploded. Vast arrays of new libraries appeared.
Many disgruntled implementors swore a might oath; that R6RS would
never darken their doors. Others couldn't have been more pleased.
Now the proposal for R7RS is to split the language into small (for
teaching, embedding, experimenting etc) and large (for those who want
to write applications without having to reimplement the whole of
computer science).
Perhaps C1x should consider this approach.
> >> Peoples' hopes for standards and
> >> compilers are bigger than realities. You might think the situation
> >> sucks for C in particular, but I don't think so.
>
> > I don't know what this means. I think the effective rejection of C99
> > is a bit sad but it's happened.
>
> In a sense, it's a curate's egg - good in parts. The problem is that
> different implementors admire different parts.
I never found much that was compelling. bool, the new sprintf and
um...
--
Nick Keighley
Nick Keighley
> Isn't there an English term for when the first version is so great that
> people mostly see no reason to upgrade afterwards?
If it ain't broke don't fix it.
Better is the ememy of good enough.
Perfection is an insult to the gods (Spanish Proverb)
"ALGOL 60 was a language so far ahead of its time that it
was not only an improvement on its predecessors but also
on nearly all its successors".
--C.A.R. Hoare
A designer knows he has achieved perfection
not when there is nothing left to add,
but when there is nothing left to take away.
Antoine de Saint-Exupéry
Fortran is like a shark, very old and effective.
Tor Rustad
C++: "an octopus made by nailing extra legs onto a dog"
-- Steve Taylor, 1998
Richard Heathfield
> In article <z62dnci2ntaZPcDW...@bt.com>, Richard Heathfield <r...@see.sig.invalid> writes:
>
>> one doesn't use C90 features that break under C99
>
> Could you please suggest a summary of those features?
Try paragraph 5 of the ISO/IEC 9899:1999 (E) Foreword.
> (Besides
> "restrict".) I guess paragraph 5 of the ISO/IEC 9899:1999 (E) Foreword
> could serve as a basis, but if there's anything pre-cooked, I'd like to
> start with that.
Um... :-)
<snip>
> I don't avoid coding for C99 because I "reject" it -- I simply have no
> choice than code for C90 if I want my code to compile *wherever* I go
Precisely so.
> Isn't there an English term for when the first version is so great that
> people mostly see no reason to upgrade afterwards?
Got your Nomex suit on? Yes, there is such a term. It's "ISO/IEC 9899:1990".
Well, okay, perhaps I don't really believe that. But I *do* believe that
the Panda Principle has contributed to the poor take-up of C99.
Flash Gordon
<snip>
> Flash, are you involved in the gcc project?
No, all my software writing is commercial. Although I did submit a
bug-report with a patch to binutils on one occasion (it was a problem
building on either SCO or AIC, I can't remember which). They chose to
fix the issue I reported in a different way, not using my patch.
--
Flash Gordon
Nick
> I never found much that was compelling [in C99]. bool, the new sprintf and
> um...
I like the // comments, although recognise the newsgroup problem.
VLAs are certainly useful - particularly when you want a scratch
workspace. Not essential - most dialects have an alloca or similar, or
you can use malloc/free. But better than the first as it's
"standardised" and better than the second because you don't have to be
as careful(!) and it's freed if you longjmp out.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Seebs
> VLAs are certainly useful - particularly when you want a scratch
> workspace. Not essential - most dialects have an alloca or similar, or
> you can use malloc/free. But better than the first as it's
> "standardised" and better than the second because you don't have to be
> as careful(!) and it's freed if you longjmp out.
The big win for me has been compound literals, actually. I love them.
Very handy, very idiomatic.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Keith Thompson
> Nick Keighley <nick_keigh...@hotmail.com> writes:
>> I never found much that was compelling [in C99]. bool, the new sprintf and
>> um...
>
> I like the // comments, although recognise the newsgroup problem.
>
> VLAs are certainly useful - particularly when you want a scratch
> workspace. Not essential - most dialects have an alloca or similar, or
> you can use malloc/free. But better than the first as it's
> "standardised" and better than the second because you don't have to be
> as careful(!) and it's freed if you longjmp out.
The problem with VLAs, as opposed to malloc/free, is that you *can't*
be as careful. There's no mechanism for detecting with a VLA is
too big to be allocated; it's just undefined behavior. Of course
the same is true for fixed-size arrays, or for any other object
with automatic storage duration. If you're not careful, though,
a VLA can become arbitrarily large depending on run-time values.
And on many systems, there's less space available for automatic
storage than for allocated storage.
As long as you limit the maximum possible size of a VLA to something
reasonable, though, this shouldn't be too much of an issue.
(Note that alloca() typically has the same problem; the documentation
on at least one system says, "If the allocation causes stack overflow,
program behavior is undefined"). Calling alloca() within a function
argument list can also cause bizarre problems.)
Richard Bos
> frank <fr...@example.invalid> writes:
> > From: "Peter J. Holzer" <hjp-usen...@hjp.at>
> > For germans, hanging on to even high german is ridiculous.
>
> Erm, are you sure he's a German?
frank doesn't even know the difference between German and Dutch.
Usually, he doesn't even make sense in English.
Richard
Anand Hariharan
(...)
> There are a handful of common examples of things which are currently
> generally regarded as being off-topic. I'll review those.
>
(...)
> 8. make and makefile issues.
>
(...)
>
> 8. make and makefile issues.
>
> I am a little torn on this, because of course, this is my primary way of using
> C, but it's also my primary way of using several other languages. I would
> tend to think that comp.unix.shell or one of the similar groups would be a
> better fit. There's enough differences between make implementations that
> a platform-specific group is probably better anyway in most cases.
>
(...)
> Other people have thoughts on this?
>
Jacob's wording relating to make was "makefile problems related to the
building of a c program". I fully support that.
Header file and source code organisation should be (is?) very much
topical, and 'make' pertaining to C is fundamentally tied to how
source files depend upon one another.
I for one do not know where to ask "How do I setup the makefile to
resolve a cyclic dependency between P.h and Q.h?" or "'make' does not
trigger a build of X.c when I changed file Y.h. How do I determine
what all source file X.c depends upon?", or "make triggers rebuilding
source that is up to date" and so on. Answers to such questions can
come only from experience and most definitely /not/ found in the
standard.
Nick
> On 2010-01-25, Nick <3-no...@temporary-address.org.uk> wrote:
>> VLAs are certainly useful - particularly when you want a scratch
>> workspace. Not essential - most dialects have an alloca or similar, or
>> you can use malloc/free. But better than the first as it's
>> "standardised" and better than the second because you don't have to be
>> as careful(!) and it's freed if you longjmp out.
>
> The big win for me has been compound literals, actually. I love them.
> Very handy, very idiomatic.
Good point. I don't use them a lot, but where I do they are great.
Particularly for some of those strange unix functions like setitimer. I
used one to great effect there (I had one parameter that came to my
function, all the rest being pre-defined).
Nick
> Nick <3-no...@temporary-address.org.uk> writes:
>> Nick Keighley <nick_keigh...@hotmail.com> writes:
>>> I never found much that was compelling [in C99]. bool, the new sprintf and
>>> um...
>>
>> I like the // comments, although recognise the newsgroup problem.
>>
>> VLAs are certainly useful - particularly when you want a scratch
>> workspace. Not essential - most dialects have an alloca or similar, or
>> you can use malloc/free. But better than the first as it's
>> "standardised" and better than the second because you don't have to be
>> as careful(!) and it's freed if you longjmp out.
>
> The problem with VLAs, as opposed to malloc/free, is that you *can't*
> be as careful. There's no mechanism for detecting with a VLA is
> too big to be allocated; it's just undefined behavior. Of course
> the same is true for fixed-size arrays, or for any other object
> with automatic storage duration. If you're not careful, though,
> a VLA can become arbitrarily large depending on run-time values.
> And on many systems, there's less space available for automatic
> storage than for allocated storage.
Although, as we've discussed, without doing some system tweaking the
same applies to malloc/free on my machine (although with less painful
problems from a security perspective, of course).
> As long as you limit the maximum possible size of a VLA to something
> reasonable, though, this shouldn't be too much of an issue.
Yes, although I strongly suspect I'm not as good as I should be there: I
"know" the input I'm making a scratch copy of will be short, but there
may be buggy circumstances when it won't.
Keith Thompson
[...]
> I for one do not know where to ask "How do I setup the makefile to
> resolve a cyclic dependency between P.h and Q.h?" or "'make' does not
> trigger a build of X.c when I changed file Y.h. How do I determine
> what all source file X.c depends upon?", or "make triggers rebuilding
> source that is up to date" and so on. Answers to such questions can
> come only from experience and most definitely /not/ found in the
> standard.
What about comp.unix.programmer? Granted, "make" is not entirely
Unix-specific, but if the answers differ from one OS to another
perhaps a different OS-specific newsgroup would be better.
Many of these questions could be equally applicable to languages
other than C. In my opinion, that should be an indication that
comp.lang.c is not the most effective place to ask them.
Note that this is a least as much about helping questioners find the
best possible answers as it is about maintaining a good signal/noise
ratio here in clc.
lawrenc...@siemens.com
> lawrenc...@siemens.com wrote:
> > In standard C, the
> > output of the preprocessor is a sequence of *tokens*, not text.
>
> Aha, is there a way to look at those tokens such that it is readable to
> ordinary mortals?
Not as far as the C Standard is concerned. Most compilers have an
option to display it as text (-E and -P are popular) but the text is
usually intended to be valid C program text so it doesn't have explicit
token delimiters and thus cannot be 100% accurate.
--
Larry Jones
These child psychology books we bought were such a waste of money.
-- Calvin's Mom
lawrenc...@siemens.com
> Nick Keighley wrote:
> > The standard is supposed to be reviewed with a shorter cycle time than
> > that.
>
> Yes. I am guessing that the shift from C0x to C1x suggests that they've
> dropped a decade either in the hope that C99 will catch on in the
> interim, or in the recognition that it won't, so that a big
> (decade-long!) re-think is required.
No, more a recognition that it wasn't going to get done by 2009. C89
was actually finalized in 1988 and got delayed a year due to a
procedural snafu, C99 just barely made 1999, and we knew we weren't
going to make 2009 for the new revision. The current plan is to have a
new standard in 2011 or 2012, so it's just a small slip from the
historical 11 year schedule, not an entire decade.
--
Larry Jones
These things just seem to happen. -- Calvin
Ersek, Laszlo
> Seebs <usenet...@seebs.net> writes:
>
>> The big win for me has been compound literals, actually. I love them.
>> Very handy, very idiomatic.
>
> Good point. I don't use them a lot, but where I do they are great.
> Particularly for some of those strange unix functions like setitimer. I
> used one to great effect there (I had one parameter that came to my
> function, all the rest being pre-defined).
In my opinion, that's not portable, unless you combine the compound
literal with designated initializers.
http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html
----v----
[OB] The <sys/time.h> header shall define the itimerval structure, which
shall include AT LEAST the following members:
struct timeval it_interval Timer interval.
struct timeval it_value Current value.
----^----
(emphasis mine). The quote is from SUSv4, but earlier versions use
similar language:
http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/time.h.html
http://www.opengroup.org/onlinepubs/007908775/xsh/systime.h.html
(I can't provide a link to SUSv1, but it's no exception either.)
Neither the order of these two members nor the positions of any
additional members are specified.
Cheers,
lacos
Ersek, Laszlo
> The big win for me has been compound literals, actually. I love them.
> Very handy, very idiomatic.
C99 6.5.2.5 "Compound literals", paragraph 10:
----v----
EXAMPLE 2 [...] in
void f(void)
{
int *p;
/*...*/
p = (int [2]){*p};
/*...*/
}
p is assigned the address of the first element of an array of two ints,
the first having the value previously pointed to by p and the second,
zero. [...]
----^----
Is the assignment correct because the end of an initializer is a
sequence point? (C99 6.5.2.5p7 and Annex C.) "p" is written to once and
read once, and the new value of "p" is not based on the previous value
of "p".
Thanks,
lacos
Nick
> In article <87vdepv...@temporary-address.org.uk>, Nick <3-no...@temporary-address.org.uk> writes:
>> Seebs <usenet...@seebs.net> writes:
>>
>>> The big win for me has been compound literals, actually. I love them.
>>> Very handy, very idiomatic.
>>
>> Good point. I don't use them a lot, but where I do they are great.
>> Particularly for some of those strange unix functions like setitimer. I
>> used one to great effect there (I had one parameter that came to my
>> function, all the rest being pre-defined).
>
> In my opinion, that's not portable, unless you combine the compound
> literal with designated initializers.
Well obviously it's not portable, that's why it's in my "adjust this bit
of code depending on your system file".
Really, though, thanks for that. I think you're right, it's not even
portable across SUS systems. Shame!
Seebs
> Jacob's wording relating to make was "makefile problems related to the
> building of a c program". I fully support that.
I don't.
Let me explain why.
I am trying to build a C program.
As part of that process, I need to debug the following hunk of GNU make
code:
$$(foreach i,$$($(1)_LDAT_indexes),@$$(foreach j,$$(wordlist $$(word $$i,$$($(1)_LDAT_starts)),$$(word $$i,$$($(1)_LDAT_ends)),$$($(1)_LDAT_list)),$$(call $(1),$$j) ; )$$(LDAT_nl))
This is absolutely in the path I use to end up causing make to invoke a C
compiler. I'm pretty sure, though, that it hasn't got a thing to do with
C.[*]
> Header file and source code organisation should be (is?) very much
> topical, and 'make' pertaining to C is fundamentally tied to how
> source files depend upon one another.
I don't think so; see above.
> I for one do not know where to ask "How do I setup the makefile to
> resolve a cyclic dependency between P.h and Q.h?" or "'make' does not
> trigger a build of X.c when I changed file Y.h. How do I determine
> what all source file X.c depends upon?", or "make triggers rebuilding
> source that is up to date" and so on. Answers to such questions can
> come only from experience and most definitely /not/ found in the
> standard.
If I were running into stuff like that, I'd probably ask in
comp.unix.programmer, if I were using make on a UNIX system... and if
I weren't, I'd probably want a group where people were likely to be using
the same "make" I was.
-s
[*] It is part of the solution to the general question "what do you do if you
want to expand a macro for each item in a large list, but the resulting
expansion may exceed the allowed length of a shell command, but you don't
want to start a separate shell for each item in the list".
Seebs
> In my opinion, that's not portable, unless you combine the compound
> literal with designated initializers.
Right.
But designated initializers are in there too, and as a result, I saved
a ton of time and visual complexity in some otherwise hairy code.
-s
Kenny McCormack
Keith Thompson <ks...@mib.org> wrote:
...
>Note that this is a least as much about helping questioners find the
>best possible answers as it is about maintaining a good signal/noise
>ratio here in clc.
Actually, Keith, it has to be (superficially, i.e., in terms of what you
will publicly admit) *entirely* a matter of "helping questioners" (i.e.,
newbies) "find the best possible answers" to their questions. Because
if it were about (to any extent at all) "maintaining a good signal/noise
ratio here in clc", then you'd have to apply these standards to the
regs.
And that clearly doesn't happen (and never will). The regs are
(obviously) free to yack and yammer about whatever they want, and you'll
never complain at all.