what parallel C language does MIPS Pro C Compiler support?

[Randy Howard]

Jordan Abel wrote

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?

I am saying that I can't see how you don't see any logic in an
argument that a more narrow topic definition is less "swamped"
than a much more broad one. More importantly, if you have a
question about something specific to a given platform, the odds
of you getting single, or even multiple correct answers are
demonstrably higher if you ask that question in a group
populated by experts on that platform. Additionally, if you get
an answer that is blatantly wrong in a group comprised that way,
the others are very likely to jump up and down and let you know
that you've been given bad information. If you ask the same
question here, and one or two people respond, because they are
the only regulars familiar with your question here, and the
information is wrong, there is no built-in check for
correctness. The WHOLE POINT of specific technical newsgroups
is focused knowledge and expertise. It is not to avoid having
to subscribe to more than one newsgroup.

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.

Feel free to demonstrate that you are in the majority, or
represent a 'significant proportion' by some other metric you
care to identify.

 

[Richard Bos]

There are general groups and more specific ones. The short name of the
newsgroup "comp.lang.c" would appear to imply

If you think the name of a newsgroup _alone_ is a good indicator of its
purpose, I suggest you try getting your fantasy gaming questions
answered in alt.fan.warlord.

Richard

 

[Dik T. Winter]

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

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

BSD 4.3 does not have a "time" systemcall, it was alread removed by
that date. As to why the argument, I think that is rooted deep in
history.

 

[Richard Heathfield]

Jordan Abel said:

I'm aware of that, but I don't see why the same idea can't apply

It could certainly apply in some other newsgroup, and anyone who wishes can
start the process to create such a group.

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.

That's a good idea, but I suggest a slight modification - why not have a
separate group for Win32 programming questions? For example, you could call
it comp.os.ms-windows.programmer.win32 - that way, people who don't want to
deal with Win32 stuff can simply not bother to subscribe to that group,
thus saving everyone a lot of time.

Is that cool, or what?

 

[Jordan Abel]

Jordan Abel said:


It could certainly apply in some other newsgroup, and anyone who wishes can
start the process to create such a group.

hmm - anyone know how to make an 'alt' newsgroup?

[thinking of 'alt.lang.c', of course]

 

[=?ISO-8859-1?Q?Bj=F8rn_Augestad?=]

Bjørn Augestad wrote


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

Agreed. I even agree with the rather narrow topicality rules here in c.l.c.

comp.lang.c.posix? Would it have enough traffic to make it
worthwhile?

If you build it, they will come? ;-)

Would it have a narrow of enough view to keep out
the homework problems and such? No and yes respectively, I
suspect.

Who knows? POSIX C is IMHO the most useful version of C and the
potential audience could be huge, but the overlap between
comp.lang.c.posix and comp.unix.programmer should not be ignored.

Wanna give it a try?

Bjørn

 

[Keith Thompson]

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]

My speculation is that some even earlier version of C didn't support
integers bigger than 16 bits, so a 32-bit integer had to be
implemented as an array of two 16-bit integers (or perhaps as a
struct).

Obviously if it were being designed today, it would make more sense to
declare it as

time_t time(void);

 

[Keith Thompson]

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.

That would be completely unenforceable. We can't even get people to
quote context properly. The volume of newbies who would post
system-specific questions without the proper tag would overwhelm the
newsgroup. Also, people would add the tags mid-thread, which would
cause some (admittedly broken) newsreaders to treat the followup as
the start of a new thread.

The proper place for such a tag is in the "Newsgroups:" header.

There are plenty of places to discuss system-specific programming.
There's only one place to discuss standard C, and it's right here
(well, 3 if you count clc, clcm, and csc). We're in no danger of
running out of things to discuss.

We can avoid the mistakes that almost destroyed comp.lang.c++.

I oppose any attempt to widen the scope of this newsgroup. The de
facto restriction to standard C is why I hang out here. (I also
sometimes participate in comp.unix.programmer.)

 

[Keith Thompson]

Jordan Abel said:


It could certainly apply in some other newsgroup, and anyone who wishes can
start the process to create such a group.

hmm - anyone know how to make an 'alt' newsgroup?

[thinking of 'alt.lang.c', of course]

Google "Usenet create alt group" (without the quotation marks).

I suggest calling it "alt.lang.c.general". Though the name of a
newsgroup doesn't necessarily tell you what it's about, it would be
good to clearly indicate that it's more general than comp.lang.c.

Let us know if you actually create it; I might even participate.

 

[Keith Thompson]

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.

Keep in mind that POSIX is an OS interface standard, not a language
standard. There are POSIX standards for languages other than C
(including one for Ada). Do you want to limit the new group to C
programs using the POSIX standard, or do you want to allow POSIX
discussion in general?

Note also that there are already comp.unix.programmer and
comp.std.unix groups.

I'm not arguing against comp.lang.c.posix, just suggesting that you
need to be aware of the full context before deciding on a name and
subject area. And if it's created, I'll probably participate, or at
least lurk.

 

[Keith Thompson]

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.

I don't believe you could construct a set of topicality rules that
would be considered reasonable by a larger proportion of the
newsgroup's population than the ones we have now.

Furthermore, it's the *experts* who would be most likely to leave if
the subject area of the newsgroup were widened. The end result would
likely be that there would be no newsgroup where people could get good
information about standard C.

 

[Jordan Abel]

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]

My speculation is that some even earlier version of C didn't support
integers bigger than 16 bits, so a 32-bit integer had to be
implemented as an array of two 16-bit integers (or perhaps as a
struct).

ah. this, however, is the kind of thing that should have been changed
before standardization, possibly before k&r. C supported a 32-bit
integer type as of unix v7.

or, even,

#define time() _timevoid()

with an alternate definition available for compatibility for older
programs:

#define time(x) _timecp(x)

Obviously if it were being designed today, it would make more sense to
declare it as

time_t time(void);

If i had a time machine.... but enough of that

 

[Jordan Abel]

I don't believe you could construct a set of topicality rules that
would be considered reasonable by a larger proportion of the
newsgroup's population than the ones we have now.

Furthermore, it's the *experts* who would be most likely to leave if
the subject area of the newsgroup were widened. The end result would
likely be that there would be no newsgroup where people could get good
information about standard C.

I'm convinced. I am going to drop the subject now.

 

[Randy Howard]

Bjørn Augestad wrote

If you build it, they will come? ;-)

For me, I don't see the need. If I want to discuss posix, I'll
go hang out in cup. I see it most as a newsgroup name to
forward OT noobs to, rather than serving some useful purpose for
me personally.

Who knows? POSIX C is IMHO the most useful version of C and the
potential audience could be huge, but the overlap between
comp.lang.c.posix and comp.unix.programmer should not be ignored.

Very true. The only reason I raised it was because whenever you
try redirecting somebody to cup, they object and start wanting
to change the charter here instead. So, having one that focuses
purely on C in a wider scope ought to help fend that off.
Theory, anyway.

Wanna give it a try?

Feel free to propose it.

 

[Randy Howard]

Keith Thompson wrote

Keep in mind that POSIX is an OS interface standard, not a language
standard.

Exactly. That's why people sometimes object to being redirected
to a group that talks more than C, so I thought "give them what
they want, just give it to them elsewhere".

Or, let them go start some web forum or something more akin to
the modern geek-to-be's.

There are POSIX standards for languages other than C
(including one for Ada). Do you want to limit the new group to C
programs using the POSIX standard, or do you want to allow POSIX
discussion in general?

I just want to improve the S/N ratio. I don't really care how
it's done.

I'm not arguing against comp.lang.c.posix, just suggesting that you
need to be aware of the full context before deciding on a name and
subject area. And if it's created, I'll probably participate, or at
least lurk.

I didn't mean the suggestion nearly as strongly as you
interpreted it.

 

[jacob navia]

Jordan Abel wrote



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.

Look, I started writing C in 1983-84, can't remember exactly.
And portability has never been an objective for me.

Never a SINGLE user has EVER asked me:
Is your program portable?

They DID ask me if it works, if it has this or that feature, if it
is easy to use, if it will do what they paid for. YES, THOSE
questions I got asked over and over.

But never nobody asked for portability.

Software has to be ported to a new environment or to a changed
environment or whatever. And the usage of nanosleep() or
GetWindowsVersionEX has never been a problem in the countless ports
I did. Those functions can be replaced by their equivalents, or
a dummy equivalent can be fixed for it whatever.

The real hard problems are underlying i/o systems, different
kinds of GUIs different word sizes, etc. Those are harder
problems when porting.

In this group, portability has been taken to the ridiculous extreme of
staying in the C89 standard, that is surely portable but at what cost???

int main(void) {printf("PORTABLE PROGRAM "\n"); }
is portable but is it useful???

 

[Richard Heathfield]

jacob navia said:

In this group, portability has been taken to the ridiculous extreme of
staying in the C89 standard,

Why is that ridiculous? I've worked on many projects where this "ridiculous
extreme" was a customer-imposed requirement. Are you saying my customers
were ridiculous for wanting portable programs?

that is surely portable but at what cost???

int main(void) {printf("PORTABLE PROGRAM "\n"); }
is portable but is it useful???

Is that really the most useful portable C code you can imagine? I'd have
thought a well-known C compiler writer would have a better imagination than
that.

 

[Chris Torek]

Look, I started writing C in 1983-84, can't remember exactly.
And portability has never been an objective for me.

Never a SINGLE user has EVER asked me:
Is your program portable?

They DID ask me if it works ...

Did they ever ask this as:

"Does it work on the SPARC, the MIPS, and/or the Alpha too?"

If so, they were asking about its portability.

... if it has this or that feature, if it
is easy to use, if it will do what they paid for. YES, THOSE
questions I got asked over and over.

Those questions are indeed common (and useful and wise).

But never nobody asked for portability.

This is possible, but if so, you did not work in the same environments
in which I worked.

Software has to be ported to a new environment or to a changed
environment or whatever. And the usage of nanosleep() or
GetWindowsVersionEX has never been a problem in the countless ports
I did.

It sounds to me, then, that you *were* asked about portability.
A portable program is one that ports -- that can be used on a
different platform.

Ultimately, portability is not a binary attribute, but rather a
gradient. Code that is entirely standard-conformant is always
easily ported (simply by recompiling) on platforms that conform
to that standard.

In this group, portability has been taken to the ridiculous extreme of
staying in the C89 standard, that is surely portable but at what cost???

The cost must always be weighed against the benefit.

The benefit is not quantifiable, here in comp.lang.c, because the
benefit achieved by non-standard code is not describable either.
(If you believe otherwise: What does adjSysIntObjPriority() do?
How much benefit is it to use it?)

The cost, here in comp.lang.c, is obvious: a program that calls
adjSysIntObjPriority() will not even compile.

Thus, in comp.lang.c, the quantified cost ("program does not
compile") always exceeds the unquantified benefit. If you want to
talk about the benefit, you need a different newsgroup.

 

[jacob navia]

Did they ever ask this as:

"Does it work on the SPARC, the MIPS, and/or the Alpha too?"

If so, they were asking about its portability.




Those questions are indeed common (and useful and wise).




This is possible, but if so, you did not work in the same environments
in which I worked.




It sounds to me, then, that you *were* asked about portability.
A portable program is one that ports -- that can be used on a
different platform.

Ultimately, portability is not a binary attribute, but rather a
gradient. Code that is entirely standard-conformant is always
easily ported (simply by recompiling) on platforms that conform
to that standard.




The cost must always be weighed against the benefit.

The benefit is not quantifiable, here in comp.lang.c, because the
benefit achieved by non-standard code is not describable either.
(If you believe otherwise: What does adjSysIntObjPriority() do?
How much benefit is it to use it?)

The cost, here in comp.lang.c, is obvious: a program that calls
adjSysIntObjPriority() will not even compile.

Thus, in comp.lang.c, the quantified cost ("program does not
compile") always exceeds the unquantified benefit. If you want to
talk about the benefit, you need a different newsgroup.

C'mon Chris pleeeze...

You do not use directories in your programs?
You always work in the current directory?

Because that is not covered by C89.

You never do any other output to the screen but using printf fwrite???
GUIs are not covered by C89

You do not use the mouse, nor any other kind of input
device?
That is not in C89

You never use the network?

The network is not in C89.

*ANY* useful program that DOES something MUST use the underlying OS in
some way or another.

 

[Randy Howard]

jacob navia wrote

Look, I started writing C in 1983-84, can't remember exactly.
And portability has never been an objective for me.

Ok. What's your point? That you represent the sum total of all
programmers? I've rarely worked on a project that didn't touch
multiple platforms, and I started long before you did. So much
for that theory.

Never a SINGLE user has EVER asked me:
Is your program portable?

See above.

The real hard problems are underlying i/o systems, different
kinds of GUIs different word sizes, etc. Those are harder
problems when porting.

Hmm, so you've never had it as an objective, yet you seem to be
aware that the issues exist. That's something.

In this group, portability has been taken to the ridiculous extreme of
staying in the C89 standard, that is surely portable but at what cost???

int main(void) {printf("PORTABLE PROGRAM "\n"); }
is portable but is it useful???

Hmm, might want to return a value, especially since you are
claiming C89. Nice try though.