What is on topic here

[spinoza1111]

Please, this is not necessary.

Richard Harter, [email protected]://home.tiac.net/~cri,http://www.varinoma.com
Infinity is one of those things that keep philosophers busy when they
could be more profitably spending their time weeding their garden.

The boors here are pretty obvious. They break their committments to
not "feed the troll" by referring to the "troll" (in this case a
person who can write) by means of cruel nicknames which potential
employers and clients can see, and boors are cowardly people who label
as "boorish" verbal self-defense of which they themselves are
incapable.

 

[spinoza1111]

And I think there should be some degree of leeway to allow discussing
them here in CLC.



Forward declarations is a hack to overcome cyclic dependencies.



Am not sure if you (mis)read what I wrote.  I was trying to respond to
Keith by saying just because other languages also have features
similar to C does not make them OT in CLC.

Of course it doesn't. Nothing can be absolutely off-topic, as I have
shown above (Weinberg's "The Psychology of Computer Programming" and
Knuth's "Art of Computer Programming" would both be flamed here). The
question is the utility of the relationship and the poster's ability
to relate A to B. This ability is deficient or missing in the regs
because they hold overspecialized corporate jobs (such as finding
compiler bugs only to pass them on). Therefore, they respond with
blind rage to the ability to connect, especially as evinced in the
ability to construct a sentence with complexity > small n.

Pl see my comment about latitude above.

Anand, the sort of low-level corporate types who post here are not
permitted either latitude or longitude and as a result of narrow, and
mostly constricted lives, combined with the sanctioned indiscipline
and fashionable ignorance, they find it impossible to relate A to
B...without going overboard. The way this is done is with grammar, and
their low abilities are on display here.

Sure, 'make' is used for other purposes, and one can use C without
make.  Please review my post couple of days ago where I was talking
about Jacob's call to include make problems /pertaining to building C/
as topical in CLC.

There is NO mechanical test for relevance: it's ultimately a matter of
an understanding which in the case of a complex chain of relevance can
parse a sentence of depth > small n and this is missing here in the
regs.

Am only saying CLC should consider a poster's difficulties in using an
implementation or a toolset that is used to work with C as topical.
If people come here with such problems, it is only because they don't
know better.  Peter's example of make's usage is clearly not topical
here since anyone with that level of knowledge of make would know to
find better help elsewhere.

As regards to the degradation of S/N ratio, methinks it can't get much
worse. :-(  Most threads that one would consider relatively 'high
signal' tend to be language minutiae concerning what is undefined.

- Anand

I am not making a brief for speaking of "shoes, and ships, and sealing
wax" nor talking about how to use C Sharp. I would say that it would
be on-topic to recommend C sharp to a newbie who's trying to use C for
an application that is naturally OO, for C's numerous deficiencies are
highly relevant to C. The newbie needs not only to know that C "rules
of thumb" such as "parenthesize formal parameters in macro
definitions" are not optional, and he needs to know why they are
important (the preprocessor was a silly and adolescent idea that
should have been drowned in the bathtub).

Some of us have in fact no problem with focus. I was hired in 1987 by
Princeton precisely because in the interview I gave evidence of some
ability to converse about academic topics other than computer science
and to relate them, and a few months later I was showing English
professors how to use Hypercard to display the structure of a poem. I
was doing my job because I was talking "about" the Mac, I was doing it
effectively because I knew that English professors teach metrical
verse by making diacritical marks on the board which could be
simulated in Hypercard.

Interestingly, some lower level employees of Information Centers found
reason to complain out of envy, for they'd been subordinated years ago
to the demands of one demanding user using some overly complex
software, and much later (after I left) I learned that Information
Centers had been told to stick to its last, and consider itself a mere
bit factory. Which reduced its effectiveness and budget but kept the
class system intact.

It is indeed innately disruptive, possibly revolutionary, to write of
"the psychology [or art] of programming". And low level bit pushers
(who think that the "heap" is an MS DOS term and who scan comp.risks
titles for names) internalize rules as a price of low-level
employability. But if usenet, or Google Groups, or whatever this
facility is, is to be useful, it must be free, and that freedom
shouldn't be used to assault people, but to speak as needed of shoes,
and ships, and sealing wax, and here, their relation to C.

 

[spinoza1111]

I haven't behaved boorishly: your information is second hand. You are
in other words yet another person who hasn't done his homework, and
for this reason you credit the word of the regulars here.

In this world, which has regressed to Lord of the Flies levels because
of the behavior of the regulars, "being an ass" is to be what you're
afraid to be: a target of criticism.

Letters have gone to lawyers about the behavior of people here. A
letter will go in particular to Peter Seebach's employer and his
publisher on his behavior.

Correction: on the advice of counsel, I will not contact Wind River
Systems or Apress about Seebach at this time.

Charlton

 

[spinoza1111]

Of course it doesn't. Nothing can be absolutely off-topic, as I have
shown above (Weinberg's "The Psychology of Computer Programming" and
Knuth's "Art of Computer Programming" would both be flamed here). The

[Sigh]. I have to be careful with Reading Rainbows who have long
learned, in a Negative Dialectic, to use their illiteracy and
aliteracy as a tactical tool: the above should read "would be flamed
in comp.programming".

 

[spinoza1111]

And you are certainly barking, Spinny. I predict that if your "case"
ever comes to court, the judge will have you sectioned within 15 minutes.

Sure you do. That's because the price of low-level employability is
believing that you are the dickless wonder that society says you are.

Then we'll be able to visit you in Bedlam and poke you with sharp sticks.

By the way, in terms of a Fool, I see Spinny as Baldrick rather than,
say, Verence II or even Magnifico.

Wow. You watch TV!

 

[Charlton Wilbur]

troll> I haven't behaved boorishly: your information is second
troll> hand.

I've seen it right here, on my own screen, with my own eyes.

I'm perfectly willing to believe that you're a boor everywhere you go,
but my opinion of you is based entirely on first-hand evidence.

Charlton

 

[Antoninus Twink]

If I am the ceremonial topicality scapegoat, it's based on a
misconception (apparently quite widely held). I actually think the
topicality of this group is too restrictive, and have said so on any
number of occasions.

How ever often you say it, your actions speak for themselves, and it's
clear to everyone that you are trying to present a holier-than-thou
exterior image of "topicality" moderation, while beneath that veneer
your true agenda is plain for all to see.

If it wags its tail and barks, I call it a dog. However many times it
protests that it's a cat.

 

[Antoninus Twink]

I disagree; I find that it's the self-proclaimed trolls who make the
most noise.

Interesting.

I thought you had killfiled these "self proclaimed trolls", so wouldn't
hear any "noise" from them at all.

Pathetic.

 

[Antoninus Twink]

I think that scales badly -- we would end up with the vast majority of the
material which was considered topical to "comp.lang.c" being stuff entirely
separate from C, not particularly specific to C, and often stuff for which
there are much better answers.
http://en.wikipedia.org/wiki/Slippery_slope_(fallacy)

I think that's the point -- I think the best response is to direct people
towards the better help. They don't know better, so let's tell them, since
that's the best possible advice.

In what way is it better than just getting on and answering their damn
question without screwing them around with redirections to this, that
and the other newsgroup, some of which often haven't been posted to for
years?

 

[spinoza1111]

    >> In fact, anyone who makes as big an ass of himself as you have
    >> *will* be called names, and if you don't like that, I recommend
    >> sticking your fingers in your ears and humming until you can hear
    >> nothing else.

    troll> I haven't behaved boorishly: your information is second
    troll> hand.

I've seen it right here, on my own screen, with my own eyes.

I'm perfectly willing to believe that you're a boor everywhere you go,
but my opinion of you is based entirely on first-hand evidence.

No, it's based on reading, where you are deficient at reading. In face
to face encounters I am civil if treated with civility.

 

[spinoza1111]

How ever often you say it, your actions speak for themselves, and it's
clear to everyone that you are trying to present a holier-than-thou
exterior image of "topicality" moderation, while beneath that veneer
your true agenda is plain for all to see.

If it wags its tail and barks, I call it a dog. However many times it
protests that it's a cat.

The guy has stated over in comp.programming that "comp.programming is
not about programmers". Here, he would not allow discussion of the
implementation of even a strict subset of C.

He's extremely insecure. I think this is the only place where he can
thrown his weight around.

 

[spinoza1111]

In what way is it better than just getting on and answering their damn
question without screwing them around with redirections to this, that
and the other newsgroup, some of which often haven't been posted to for
years?

Excellent point. If the smaller and more specialized group is either
unmanned or inhabited by regs even dumber than the "experts" here, the
regs here may feel all nice, having conformed to a Rule. The question
asker is fucked, but that doesn't matter since the regs have conformed
to the Rule. It's similar to the way they get a hard-on when they tell
a questioner that behavior is undefined, or that something can't be
done, since their ignorance is not exposed when their questioner has
to prove a negative.

These guys so love the dysfunctional corporate world of silly rules
and CYA (cover your ass) that they actually recreate it here,
including back-stabbing, calling people cruel names, and talking
behind people's backs (being so dumb as not to realize that they're
overheard when they do that here).

So we see the Homunculus define what it is to be human
So we see the Trogdolyte take delight
In confusin' long but correct sentence structure with fumin'
Calling his night day and the day of truth, night.
Heathfield rants on and on and on
About what is C from his toxic pond in rural Northumberland
Kiki draws his skirts up and shudders in dismay
Saying "you're in my kill file, and what is that you say?"
Seebie brags about his lack of chops
Having bought his meal ticket at the finer shops,
And from time to time Rosenau checks in from Nazi Camp
With spittle fleck'd mouth running rather moist and rather damp
To agree with the regular thugs
It's quite a collection of mugs.

 

[blmblm]

[ snip ]

Your lack of computer science is showing. In fact, the underlying
concepts are the same. What part of "semaphores" don't you
understand?

What makes you think Seebs doesn't understand semaphores?

I would be interested in hearing, from Seebs, what sort of differences
he had in mind when he wrote the sentences quoted above.

I'll also comment in passing that the multithreaded programming
environments I'm most familiar with (OpenMP, POSIX threads, Java)
either don't provide explicit semaphores at all or provide them
in addition to other synchronization mechanisms that are apt to
be more useful to application developers.

This is a common mistake of the sort of programmer who falls into
programming by accident: to actually believe that there are mysterious
("undefined", "undefinable") differences between platforms, and to
often conclude that "my platform is better" without knowing why.

.Net (which isn't Windows, of course) has in fact a very clean
implementation of semaphores.

I'd be interested in hearing, from people knowledgeable about
writing multithreaded code in .Net, whether they use these
semaphores directly, or whether there are other synchronization
constructs that are more useful.

[ snip ]

 

[blmblm]

[ snip quoted signature ]

We have to read this post in conjunction with your stunning level of
ignorance about computer science and lack of real qualifications, Mr.
Seebach:

1. The "heap" is NOT an MS-DOS artifact

Did he ever actually say it was? Well, perhaps I don't understand
what you mean by "artifact" here. What Seebs actually said, in his
Web page critiquing Schildt's book(s), was that "heap" was "a DOS
term", and he clarified in message ID

<[email protected]>

as follows:

None of that strikes me as a display of "stunning ignorance". ?

2. Windows and unix, to be functional for multiple threads, have to
implement atomic semaphores: this was a scientific result on the order
of relational data base

Are you using the term "atomic semaphores" to mean something different
from semaphores as proposed by Dijkstra and discussed in textbooks on
operating systems? Just curious.

I'm also curious about why an operating system has to implement
semaphores, as opposed to some other synchronization mechanism --
or perhaps you're using "semaphores" here in a rather generic
sense that would include equivalent mechanisms such as monitors
(as proposed by Hoare and Brinch Hansen)?

[ snip ]

 

[Ersek, Laszlo]

I'll also comment in passing that the multithreaded programming
environments I'm most familiar with (OpenMP, POSIX threads, Java)
either don't provide explicit semaphores at all or provide them
in addition to other synchronization mechanisms that are apt to
be more useful to application developers.

A semaphore can be implemented with a (mutex, condvar, counter) triplet;
indeed I had to do so once on OpenVMS. Nonetheless, the notion of the
semaphore is a nice compact one and I believe it was useful to
standardize (not in C, but still).

http://www.opengroup.org/onlinepubs/007908775/xsh/semaphore.h.html

The functions specified in N1425

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1425.pdf

7.24.3 Condition variable functions
7.24.4 Mutex functions

should make manual implementations of semaphores possible in standard C
in the future.

Cheers,
lacos

 

[Ersek, Laszlo]

(I apologize for the self-followup.)

A semaphore can be implemented with a (mutex, condvar, counter) triplet;
indeed I had to do so once on OpenVMS.

If anybody cares, grab "udp_copy2.tar.gz" from http://lacos.hu and look
at "bigpipe.c". There's one caveat: the implementation relies on there
being only one consumer thread and thus calls pthread_cond_signal()
instead of pthread_cond_broadcast() in sem_post().

Cheers,
lacos

 

[Keith Thompson]

What makes you think Seebs doesn't understand semaphores?

[...]

What make you think arguing with spinoza1111 will ever generate
anything but more noise?

 

[Tim Rentsch]

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. [snip elaboration]

I feel obliged to point out that these comments apply only to
automatic variables that are actual variable length arrays. The
VLA mechanism also allows types that are _pointers_ to variable
length arrays, and these offer the benefits of variable length
arrays, especially used as parameters, without the "dangerous"
aspect mentioned above. A pointer to variable length array can
be used to access both ordinary (non-variable length) arrays and
non-fixed length arrays allocated using malloc().

 

[Tim Rentsch]

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

But the old value of p is read _to determine_ the new value of
p. The fragment above is analogous to 'p = p->next', both
of which are legal.

 

[blmblm]

A semaphore can be implemented with a (mutex, condvar, counter) triplet;
indeed I had to do so once on OpenVMS. Nonetheless, the notion of the
semaphore is a nice compact one and I believe it was useful to
standardize (not in C, but still).

Indeed (and I think all you need for an implementation is something to
guarantee mutual exclusion plus something to make processes/threads
sleep/awaken). I believe one can formally prove that all of the
basic synchronization mechanisms (semaphores, monitors, etc.) are
in some sense equivalent.

I posted as I did because I wondered why spinoza1111 singled out
semaphores as a synchronization mechanism, when in my experience
other mechanisms are more apt to be used in application programs.
Possibly in other domains things are different.