what parallel C language does MIPS Pro C Compiler support?

J

Jordan Abel

And as for what the group "should" be about, that's spelled out by the
name: "comp.lang.c" is nothing but an abbreviation for "computer
language C". And there is one and only one internationally recognized
definition of the C programming language, the ANSI/ISO/IEC standard.

I've read, from a google archived thread on a similar issue, that there
are three, one of which was published in 1978. [the other two are
ANSI/ISO standards]

Besides - C is still C even when there are extensions.

The policy on the IRC channel ##c on freenode is that if people are
using extensions or non-standard libraries, that they should spell out
exactly what they are using. I think this is more constructive than
simply banning such questions altogether.

There's plenty of room in this newsgroup.
 
J

Jordan Abel

Actually the first message in this newsgroup dates from 22 October 1982.
But that was before the grand newsgroup renaming, and at that time the
group was called 'net.lang.c'.


In the course of time the restriction of clc to non platform-specific
uses grew in the course of time. Mainly because platform-specific
newsgroups emerged and so there was no need to have such discussions
in this newsgroup. If you look at early messages you will find that
*most* are about very platform-specific questions (Unix C). And although
most of the time it is written that only standard C is on-topic, in my
opinion that is not entirely true. In my opinion K&R C is also on-topic.
More so because in many cases that explains why things are as they are
in C, and also some of the coding people may find in programs that are
available.

So in other words, to discuss just what the historical reasons are.

On that subject - why does time() take a pointer argument? Even in UNIX
v7 [where K&R C grew up] the underlying system call returned a value
rather than placing it in memory at a pointer. [and even there, the
library call also took a pointer argument]
 
S

Simon Biber

Jordan said:
Jordan Abel said:

Please moderate your language; this is a family show.

Sorry, i'm not used to thinking of that expression as being foul
language at all - there are regional and local differences [and, this
being a college town...]

Don't worry, it wouldn't be considered rude here in Australia either,
just informal. Though, it should be spelt 'smart-arse'. :) The
alternative 'smart-alec' strikes me as merely a euphemism, though it may
well have been the original.
 
K

Kenny McCormack

Jordan Abel said:
On that subject - why does time() take a pointer argument? Even in UNIX
v7 [where K&R C grew up] the underlying system call returned a value
rather than placing it in memory at a pointer. [and even there, the
library call also took a pointer argument]

Allow me to be the first to say this - and I say it from the deepness of my
heart, with all the kindness and love one has come to associate with the
helpful posts you get in this newsgroup:

Not portable. Can't discuss it here. Blah, blah, blah.
 
J

Jordan Abel

Jordan Abel said:
On that subject - why does time() take a pointer argument? Even in UNIX
v7 [where K&R C grew up] the underlying system call returned a value
rather than placing it in memory at a pointer. [and even there, the
library call also took a pointer argument]

Allow me to be the first to say this - and I say it from the deepness of my
heart, with all the kindness and love one has come to associate with the
helpful posts you get in this newsgroup:

Not portable. Can't discuss it here. Blah, blah, blah.

While unix v7 certainly isn't portable by modern standards, the fact
that time() takes a pointer argument is part of the standard, and I
believe the question of why this is the case would be on-topic even by
the strictest definition.
 
R

Richard Heathfield

Jordan Abel said:
I meant the claim that there is a majority who agree with you at all,
and who consider questions other than strict c89/c99-based ones to be
off-topic at all. Note that it's hardly unreasonable, just unproven. And
it's equally reasonable that the opposite is true.

I don't suppose for a moment that a majority would necessarily agree with
me. I do think, however, that relaxation of topicality "rules" would have a
self-reinforcing effect. Let's call the sort of articles you want to become
topical, but which are currently-off-topic, C.O.T.:

1) clc relaxes topicality rules: COT articles become topical.
2) People here start answering COT articles. Expertise on the relevant
platforms is relatively low (compared to existing C expertise, which is
very high and on which the reputation of this group currently rests), so
the answers aren't necessarily very good.
3) People see that COT articles are now getting answers. They post their own
COT articles. These tend to relate either to Platform X or Platform Y, both
of which already have strong Usenet groups.
4) Relative density of pure C articles goes down.
5) C experts who aren't interested in Platform X or Platform Y (perhaps
because they use Platform Z exclusively, or perhaps because they have to
use all kinds of platforms, not just X or Y) start to treat clc in a much
more desultory way. The frequency of their posting begins to drop -
possibly not as a conscious decision, but simply because they have nothing
to say on Platform X or Platform Y.
6) Those who learn a lot about C from those experts but who also are good
enough to answer C questions competently, search in vain for articles from
the experts. They start to get less value from the group, so they start to
pay it less attention. Posting frequency of C articles drops absolutely as
well as (continue from Step 4).

This wouldn't happen overnight - but it would happen nonetheless. And before
very long, you'd have a completely useless group, whose most interesting
discussions would almost certainly be pointless Win32/Linux flame wars.
 
R

Richard Heathfield

Jordan Abel said:
The policy on the IRC channel ##c on freenode

This is not IRC, freenode, or ##c.
There's plenty of room in this newsgroup.

No, not really. It already generates so much traffic that I can't read every
single article. I simply don't have time to do that. I wish I did.
 
J

Jordan Abel

Jordan Abel said:


This is not IRC, freenode, or ##c.

I'm aware of that, but I don't see why the same idea can't apply
No, not really. It already generates so much traffic that I can't read every
single article. I simply don't have time to do that. I wish I did.

How about subject flags - say, someone who has a question, or an answer,
relating to win32, can put [Win32] in their subject line, and someone
who doesn't want to deal with Win32 stuff can ignore it.
 
L

Lew Pitcher

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jordan Abel wrote:
[snip]
How about subject flags - say, someone who has a question, or an answer,
relating to win32, can put [Win32] in their subject line, and someone
who doesn't want to deal with Win32 stuff can ignore it.

How about just directing all your off-topic questions to rec.food.cuisine.jewish
It will be just as on-topic as posting it here.

- --
Lew Pitcher
IT Specialist, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFDgcolagVFX4UWr64RAl6vAKDZY3zwIjv7naOIG/tWFTkNHU+0qQCeKq6M
MjV4j7zFHM95LNJrU6zgp70=
=h5C6
-----END PGP SIGNATURE-----
 
J

Jordan Abel

How about just directing all your off-topic questions to
rec.food.cuisine.jewish It will be just as on-topic as posting it
here.

This post is the first i've seen here that doesn't at least acknowledge
that there are degrees of off-topicness
 
K

Kenny McCormack

Jordan Abel said:
While unix v7 certainly isn't portable by modern standards, the fact
that time() takes a pointer argument is part of the standard, and I
believe the question of why this is the case would be on-topic even by
the strictest definition.

You may be right. I wouldn't know. But see how arbitrary the distinction
is. I.e., the concept of the time() function certainly sounds "Unix-y" to
me and I could certainly imagine platforms on which C would run just fine
but which might have other notions of time and the epoch (*).
But, then, you're a troll.

Indeed, and so are you, which is why I like you. Heretics, unite!

(*) Before anybody bothers to write, yes, I'm perfectly aware that if the
standard requires the Unix-y notions of time, then it can be said that
a platform that doesn't support Unix-y time functions isn't running C.
 
K

Kenny McCormack

This post is the first i've seen here that doesn't at least acknowledge
that there are degrees of off-topicness

Then you haven't been around long enough.

See, that's the whole point - the limited version of the topicality police
faction might almost be reasonable, but some of the real loonies take it to
extreme.
 
J

Jordan Abel

You may be right. I wouldn't know. But see how arbitrary the distinction
is. I.e., the concept of the time() function certainly sounds "Unix-y" to
me and I could certainly imagine platforms on which C would run just fine
but which might have other notions of time and the epoch (*).

time_t isn't allowed to be an array, though, so no matter what type it
happens to be, it will always be possible to return it. [It's not
allowed to be a struct, either, which I think is a mistake. Using -1 as
an error representation was also a mistake, since it doesn't forbid -1
to also be a valid time]
 
R

Randy Howard

Bjørn Augestad wrote
(in article said:
I guess you're right, but c.u.p. has so much more than POSIX C and
threading stuff is mostly discussed in comp.programming.threads. At the
same time, the heaviest C expertise is in c.l.c. Having just one place
to discuss all parts of POSIX C would be nice, at least for me.

I agree, but I think it's fairly clear that clc isn't it.

comp.lang.c.posix? Would it have enough traffic to make it
worthwhile? Would it have a narrow of enough view to keep out
the homework problems and such? No and yes respectively, I
suspect.
 
R

Richard Bos

Jordan Abel said:
Jordan Abel said:


No, not really. It already generates so much traffic that I can't read every
single article. I simply don't have time to do that. I wish I did.

How about subject flags - say, someone who has a question, or an answer,
relating to win32, can put [Win32] in their subject line, and someone
who doesn't want to deal with Win32 stuff can ignore it.

How about posting win32 questions to microsoft.win32.vcc++.net.whatever,
where the experts on win32 programming are, and Posix questions to
comp.unix.programmer, where the Posix experts hang out, and the Standard
ISO and K&R C questions here, where the pure C experts (and I, too) read
and post? That's why we have more than one newsgroup on Usenet, you
know.

Richard
 
R

Randy Howard

Jordan Abel wrote
(in article said:
And as for what the group "should" be about, that's spelled out by the
name: "comp.lang.c" is nothing but an abbreviation for "computer
language C". And there is one and only one internationally recognized
definition of the C programming language, the ANSI/ISO/IEC standard.

I've read, from a google archived thread on a similar issue, that there
are three, one of which was published in 1978. [the other two are
ANSI/ISO standards]

Not to disparage anyone else, but Jack just gave you one of the
most clearly thought out and well-intentioned responses in this
thread, to which none of the meat seemed to have arrived at its
intended destination. That is unfortunate.
Besides - C is still C even when there are extensions.

No, it is not. The only way you could think that is for you to
be relatively new to using it, particularly on cross-platform
projects. Go ahead and try to get nanosleep() or
GetWindowsVersionEX() to compile on multiple systems and
multiple compilers. Good luck. After you've been around the
block more than enough to break a light sweat, you'll realize
how silly the above comment looks to those that were doing it
while you were in diapers.
The policy on the IRC channel ##c on freenode is that if people are
using extensions or non-standard libraries, that they should spell out
exactly what they are using. I think this is more constructive than
simply banning such questions altogether.

Then by all means, spend more time on IRC. It sounds like
exactly what you are looking for. Why the effort to create two
of something, where you apparently already enjoy the existing
one? That's like saying that you love your floor plan, and want
to burn down somebody else's house so that they can also have a
home with your floor plan.
There's plenty of room in this newsgroup.

.... for people that are interested in learning, improving, or
helping others with standard C. And oh by the way, learning how
to do the core standard C sandbox "correctly" is 95% of the
battle in learning how to use platform-specific extensions
properly as well. By the time you feel you have nothing left to
learn about C from reading this newsgroup you will either be
dead, or so capable that no platform-specific library API will
pose the slightest problem for you unless it is broken and not
available for correction in source-code form.
 
R

Randy Howard

Jordan Abel wrote
(in article said:
This post is the first i've seen here that doesn't at least acknowledge
that there are degrees of off-topicness

Would it have been substantively different if he had said "post
your questions about Linux kernel extensions to
comp.os.ms-windows.networking.tcp-ip ?

You see, people ask about both here, and if they are both
on-topic here, then they must overlap enough to make them on
topic in that group, right? Using your logic, I mean.
 
J

Jordan Abel

Not to disparage anyone else, but Jack just gave you one of the
most clearly thought out and well-intentioned responses in this
thread, to which none of the meat seemed to have arrived at its
intended destination. That is unfortunate.

You're saying i didn't get what he's saying just because i don't agree
that having a different definition of what's on-topic will lead to the
group being "swamped" with off-topic posts?

If the rules for what is on-topic are considered unreasonable by a
significant proportion of the newsgroup's population, that leads to a
lack of respect for on-topic-ness in general.
 
J

Jordan Abel

Jordan Abel wrote


Would it have been substantively different if he had said "post
your questions about Linux kernel extensions to
comp.os.ms-windows.networking.tcp-ip ?

You see, people ask about both here, and if they are both
on-topic here, then they must overlap enough to make them on
topic in that group, right? Using your logic, I mean.

My logic does not imply that.

There are general groups and more specific ones. The short name of the
newsgroup "comp.lang.c" would appear to imply it's one of the general
ones, whereas the policy of some of its members seems to be that it's
one of the more specific ones.
 
R

Randy Howard

Jordan Abel wrote
(in article said:
There are general groups and more specific ones. The short name of the
newsgroup "comp.lang.c" would appear to imply

Perhaps it does appear as such, to someone new to Usenet. The
fact is, short names were common before there were tens of
thousands of Usenet groups, and longer names became necessary
simply to guarantee uniqueness.
it's one of the general
ones, whereas the policy of some of its members seems to be that it's
one of the more specific ones.

It's been quite specific for a /long/ time. Far longer than IRC
has even existed. If you wish to start a general group, adopt
the convention used in a lot of regional newsgroups, and go for
comp.lang.c.general and propose it. I for one would support it,
simply because it would be likely to remove a lot of the OT
traffic here (until it dies that is). While you're at it,
propose comp.lang.c.domyhomework too.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,575
Members
45,053
Latest member
billing-software

Latest Threads

Top