Hi friends,
I need to write a parallel code in 'C' on the server that is
running SGI Irix 6.5. This server supports MIPS Pro C compiler. I don't
have any idea of parallel C languages. I looked into few posts in this
group. I could make out that there are several languages for parallel
programming and parallel C is one of them. I need to know if this is
supported by MIPS Pro C Compiler. Or are there any other parallel C
languages that have this feature?
It would be more helpful if someone explains the differences
among mpC, paralle C, parallel C in OpenMP and MPI. To which language
does the following directives belong to.
#pragma parallel
#pragma pfor
#pragma synchronize
Thanks in advance
Ramya
Nov 20 '05
126  4174 
In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> wrote:
.... 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.
In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> wrote: On 2005-11-21, Lew Pitcher <Le*********@td.com> wrote:
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
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.
On 2005-11-21, Kenny McCormack <ga*****@yin.interaccess.com> wrote: In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> wrote:
...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 (*).
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]
(*) 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.
Bjørn Augestad wrote
(in article <O-********************@telenor.com>): pete wrote: Bjørn Augestad wrote: Mark McIntyre wrote:
The simplest solution is to create a new group
comp.lang.nonstandard-c
or something like that.
Good idea, how about comp.lang.posix.c?
I think comp.unix.programmer
would be a better name to call that one.
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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Jordan Abel <jm****@purdue.edu> wrote: On 2005-11-21, Richard Heathfield <in*****@invalid.invalid> wrote: Jordan Abel said:
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.
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
Jordan Abel wrote
(in article <sl********************@random.yi.org>): On 2005-11-21, Jack Klein <ja*******@spamcop.net> wrote: 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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Jordan Abel wrote
(in article <sl********************@random.yi.org>): On 2005-11-21, Lew Pitcher <Le*********@td.com> wrote:
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
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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
On 2005-11-21, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
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.
On 2005-11-21, Randy Howard <ra*********@FOOverizonBAR.net> wrote: Jordan Abel wrote
(in article <sl********************@random.yi.org>):
On 2005-11-21, Lew Pitcher <Le*********@td.com> wrote:
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
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.
Jordan Abel wrote
(in article <sl********************@random.yi.org>): 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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Jordan Abel wrote
(in article <sl********************@random.yi.org>): On 2005-11-21, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
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?
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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Jordan Abel <jm****@purdue.edu> wrote: 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
In article <sl********************@random.yi.org> Jordan Abel <jm****@purdue.edu> writes: On 2005-11-21, Dik T. Winter <Di********@cwi.nl> wrote:
.... 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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jordan Abel said: On 2005-11-21, Richard Heathfield <in*****@invalid.invalid> wrote: Jordan Abel said:
The policy on the IRC channel ##c on freenode
This is not IRC, freenode, or ##c.
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.
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.
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? :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
On 2005-11-21, Richard Heathfield <in*****@invalid.invalid> wrote: Jordan Abel said:
On 2005-11-21, Richard Heathfield <in*****@invalid.invalid> wrote: Jordan Abel said:
The policy on the IRC channel ##c on freenode
This is not IRC, freenode, or ##c.
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.
hmm - anyone know how to make an 'alt' newsgroup?
[thinking of 'alt.lang.c', of course]
Randy Howard wrote: Bjørn Augestad wrote
(in article <O-********************@telenor.com>):
pete wrote: Bjørn Augestad wrote:
Mark McIntyre wrote:
> The simplest solution is to create a new group
> comp.lang.nonstandard-c
> or something like that.
Good idea, how about comp.lang.posix.c?
I think comp.unix.programmer
would be a better name to call that one.
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.
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
Jordan Abel <jm****@purdue.edu> writes:
[...] 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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jordan Abel <jm****@purdue.edu> writes: On 2005-11-21, Richard Heathfield <in*****@invalid.invalid> wrote: Jordan Abel said:
The policy on the IRC channel ##c on freenode
This is not IRC, freenode, or ##c.
I'm aware of that, but I don't see why the same idea can't apply
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.
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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jordan Abel <jm****@purdue.edu> writes: On 2005-11-21, Richard Heathfield <in*****@invalid.invalid> wrote: Jordan Abel said:
On 2005-11-21, Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said:
> The policy on the IRC channel ##c on freenode
This is not IRC, freenode, or ##c.
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.
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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Randy Howard <ra*********@FOOverizonBAR.net> writes:
[...] 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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jordan Abel <jm****@purdue.edu> writes: On 2005-11-21, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
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.
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.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On 2005-11-21, Keith Thompson <ks***@mib.org> wrote: Jordan Abel <jm****@purdue.edu> writes:
[...] 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
On 2005-11-21, Keith Thompson <ks***@mib.org> wrote: 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.
--
I guess people on usenet _can_ be convinced of an opinion contrary to
their own. However, this has the unfortunate consequence that pointless
debate is no longer pointless, so this information should be suppressed
for the greater good.
Bjørn Augestad wrote
(in article <2p********************@telenor.com>): Randy Howard wrote: comp.lang.c.posix? Would it have enough traffic to make it
worthwhile?
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. :-)
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.
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 (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Keith Thompson wrote
(in article <ln************@nuthaus.mib.org>): Randy Howard <ra*********@FOOverizonBAR.net> writes:
[...] 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.
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. :-)
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Randy Howard wrote: Jordan Abel wrote
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.
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???
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
In article <43**********************@news.wanadoo.fr>
jacob navia <ja***@jacob.remcomp.fr> wrote: 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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Chris Torek wrote: In article <43**********************@news.wanadoo.fr>
jacob navia <ja***@jacob.remcomp.fr> wrote:
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.
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.
jacob navia wrote
(in article <43**********************@news.wanadoo.fr>): 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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Richard Heathfield wrote: 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.
Look:
You do not use directories in your programs?
You always work in the current directory?
Because that is not covered by standard C.
You never do any other output to the screen but using printf/fwrite???
GUIs are not covered by standard C.
You do not use the mouse, nor any other kind of input
device?
That is not in standard C.
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 wrote:
Hmm, might want to return a value, especially since you are
claiming C89. Nice try though.
No. C99 specified that the default value of main() is zero.
Crazy isn't it?
But it is standard C.
On 2005-11-21, jacob navia <ja***@jacob.remcomp.fr> wrote: Richard Heathfield wrote:
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.
Look:
You do not use directories in your programs?
You always work in the current directory?
Because that is not covered by standard C.
Neither are filenames, for that matter. Any filenames used must be
user-provided for this reason. Unless you use tmpfile/tmpname.
jacob navia wrote: Richard Heathfield wrote:
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.
Look:
You do not use directories in your programs?
You always work in the current directory?
Because that is not covered by standard C.
You never do any other output to the screen but using printf/fwrite???
GUIs are not covered by standard C.
You do not use the mouse, nor any other kind of input
device?
That is not in standard C.
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.
Nope. You can write, say, a finite element toolbox from triangulation
over assembly of matrices to solution of the resulting linear equations
(or the same for non-linear dynamic problems) completely in standard C.
Of course, some graphical preprocessing makes input of problems easier
and postprocessing makes the output easier to use but the question "will
this thing show non-elastic deformations or break?" can be answered
without.
Or think of command line tools.
You can write grep or sed (or at least the part of their functionality
I need) in standard C.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
In article <43**********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote: int main(void) {printf("PORTABLE PROGRAM :-)"\n"); }
is portable but is it useful???
That's odd... I can't get it to compile under gcc or under SGI's cc.
gcc reports 2 errors, and SGI's cc reports 5.
Which compiler did you try it with, and which compile options?
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
jacob navia <ja***@jacob.remcomp.fr> writes: Richard Heathfield wrote: 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.
Look:
You do not use directories in your programs?
You always work in the current directory?
Because that is not covered by standard C.
You never do any other output to the screen but using printf/fwrite???
GUIs are not covered by standard C.
You do not use the mouse, nor any other kind of input
device?
That is not in standard C.
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.
There are useful programs that do not use anything beyond what's
guaranteed by the C standard (C90, C99, whatever). (No, I don't have
an example off the top of my head.)
And yes, there are many useful programs that use features beyond what
the language guarantees -- but if they're well written, the
system-specific portions are separated from the portions that can be
ported with a simple recompilation. The latter portions are topical
for comp.lang.c. The system-specific portions are topical for a
newsgroup that deals with whatever system they're specific to.
Nobody here has claimed that there's anything wrong with writing
system-specific code when it's necessary. The only claim is that this
isn't the appropriate place to discuss it, and that there are plenty
of newsgroups where such things can be discussed.
I can write a C program that prints a message in Italian; that doesn't
make Italian grammar topical.
You advocate changing the topicality conventions for the newsgroup so
that system-specific discussions are allowed. That was tried some
years ago in comp.lang.c++, and it nearly destroyed the newsgroup.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia wrote
(in article <43**********************@news.wanadoo.fr>): Randy Howard wrote:
Hmm, might want to return a value, especially since you are
claiming C89. Nice try though.
No. C99 specified that the default value of main() is zero.
The return value you mean?
Crazy isn't it?
Which is why I was careful to point out your claim, which you
snipped, that it was "staying in C89". Which in point of fact,
it was not. If you can't even formulate a C89 compliant hello
world program, why should we expect you to understand any of the
rest of this thread?
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
In article <dl*********@news3.newsguy.com> I wrote, in part: The cost [of a non-portable construct] 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.
In article <43***********************@news.wanadoo.fr>
jacob navia <ja***@jacob.remcomp.fr> answered with:You do not use directories in your programs?
You always work in the current directory?
This depends on the code. Much of my code does not use files at
all. Other code actually implements the underlying file system,
but to "use a directory" you do things like:
dvp = nd.ni_dvp;
error = VOP_READDIR(dvp, ...);
Do you believe I should post about this here in comp.lang.c? Will
you find such information useful?
Because that is not covered by C89.
I never said it was. I said: "the cost must be weighed against
the benefit." The benefit of the above (nonportable) code is not
quantifiable here in comp.lang.c, but the cost is clear: the above
will not work on Windows-based systems, nor on POSIX systems even
though it happens to be an internal implementation *of* a POSIX
system.
You never do any other output to the screen but using printf fwrite???
Many of the computers I program today do not even have a "screen".
(They do have serial ports.)
GUIs are not covered by C89
Indeed. But I have not programmed GUIs for almost a decade now.
You do not use the mouse, nor any other kind of input device?
Again, many of the computers I program today do not have a mouse
(or a keyboard, just a serial port).
You never use the network?
Not the way you think about it.
*ANY* useful program that DOES something MUST use the underlying OS in
some way or another.
Substitute "any useful hosted-implementation C program" for "any
useful program", and "underlying implementation" for "underlying
OS", and yes, it must -- but the only things guaranteed to be
*in* that underlying implementation are those in the standard(s)
to which it conforms. The only standards that are on topic here
in comp.lang.c are the C standards (C89, C95, and C99, mainly,
although even K&R-1 C is still reasonably topical, in my opinion).
And, as I said, the cost of a nonportable function must always be
weighed against the benefit. This equation is much clearer when
one is outside comp.lang.c: if you need to walk a directory, and
opendir(), readdir(), closedir() etc all exist because you are in
comp.unix.programmer, the benefit to using them is obvious. The
cost is also minimal, since they are POSIX-standard. The fact that
readdir() on vxWorks happens to be implemented via a "magic" ioctl()
is not important, and the cost of using the ioctl() directly is
clear (it does not work at all on Unix and Linux) while the benefit
is tiny. But in comp.lang.c, POSIX itself is off-topic, and only
the cost ("not available in the C standards") is clear.
Do you believe I should use comp.lang.c to talk about the benefit
of semBCreate() vs semMCreate()? Should I use this newsgroup to
describe the rtpSpawn() function? What will you get out of a
discussion of the parameters to ataDevCreate()?
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
On Mon, 21 Nov 2005 00:30:43 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote: On 2005-11-20, Mark McIntyre <ma**********@spamcop.net> wrote: The point you're missing is that it /does/ have a clear and agreed on
defintion. Its just not written down.
Clearly, it's either not agreed-on, or it's agreed-on but vague enough
that there are differences in interpretation.
I disagree - there are some people who believe the topic ought to be
different, but there's almost never a difference of opinion. Even if
there were, so what? We're grownups, we're allowed to disagree.
Not only has it not been
written down, it has never been subject to a vote.
it /was/ subject to a vote, back when the group was formed. I'm not
aware there's any requirement to revote.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Mon, 21 Nov 2005 02:00:33 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote: A group for general C discussion. If you want a group for talking about
ISO C only, why not make groups comp.lang.c.iso90 comp.lang.c.iso99?
Two reasons I can think of
1) why ?
2) we were here first.
If you want a group to talk about nonstandard general stuff, go form
one called comp.lang.c.generaldiscussion
This newsgroup's charter is not in writing and has never been subject to
a vote. From what does its authority derive?
From what does your authority to start bullying everyone derive?
Okay, seems you're a troll, You start getting treated like one.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Mon, 21 Nov 2005 02:18:23 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote: On 2005-11-21, pete <pf*****@mindspring.com> wrote: Jordan Abel wrote:
This newsgroup's charter is not in writing and has never been subject
to a vote. From what does its authority derive?
Mob rule, and that's the way we like it.
Mob rule requires a vote.
Don't be an idiot.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Mon, 21 Nov 2005 13:19:27 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote:
How about subject flags
How about you just bugger off?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Mon, 21 Nov 2005 12:18:58 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote: On 2005-11-21, Jack Klein <ja*******@spamcop.net> wrote: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,
Then you're hard of reading, and/or dense and/or being deliberately
obtuse and provocative. I know not which though I have my suspicions
Besides - C is still C even when there are extensions.
No its not, any more than water is still water after you add HNO3 or
NaCl, or some other small addition.
There's plenty of room in this newsgroup.
And there's plenty of room for new groups.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Mon, 21 Nov 2005 21:28:27 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Never a SINGLE user has EVER asked me:
Is your program portable?
Its self-evident that you work almost exclusively for a single
platform. So why would they ask for portability?
But never nobody asked for portability.
Not even from Win16 to Win32? Or Win32 to Win64? But then you may not
have been around long enough for that.
Software has to be ported to a new environment or to a changed
environment or whatever.
And it never occured to you to minimise the amount of work by writing
maximally portable code in the first place?
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???
This remark makes no sense as firstly its not a ridicolous extreme,
and secondly there is no cost.
(snip fatuous example which demonstrates only the lack of
understanding of the previous poster)..
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Mon, 21 Nov 2005 22:26:28 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: You do not use directories in your programs?
<sarcasm> Whats a "directory"? </sarcasm>
You always work in the current directory?
You pass an implementation-specific string to the stream IO routines,
and get back a file handle. It will astound you to know that this
works perfectly well without having to change directory.
GUIs are not covered by standard C.
Exactly, because on every single platform, the routines needed to
drive them are different. Why are you making our point for us?
*ANY* useful program that DOES something MUST use the underlying OS in
some way or another.
Irrelevant - it can still be entirely portable (consider a filter) or
largely portable with nonportable elements separated into different
modules.
It will astound you to realise that 90% of most programmes doesn't
need to access the hardware at all.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Mon, 21 Nov 2005 21:35:40 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote: navia wrote Because that is not covered by standard C.
Neither are filenames, for that matter.
You're dead wrong.
I could quote the relevant section of the standard, but its more
instructive to leave you to find it yourself.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Mon, 21 Nov 2005 12:50:42 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote: On 2005-11-21, Kenny McCormack <ga*****@yin.interaccess.com> wrote: In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> wrote:
...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]
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.
It is - kenny is a troll.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Mark McIntyre <ma**********@spamcop.net> writes: On Mon, 21 Nov 2005 02:00:33 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote:
[...] This newsgroup's charter is not in writing and has never been subject to
a vote. From what does its authority derive?
From what does your authority to start bullying everyone derive?
Okay, seems you're a troll, You start getting treated like one.
Mark, since Usenet is an asynchronous medium, you probably missed
the followup in which Jordan wrote:
] I'm convinced. I am going to drop the subject now.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On 2005-11-22, Mark McIntyre <ma**********@spamcop.net> wrote: On Mon, 21 Nov 2005 21:35:40 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote:
navia wrote Because that is not covered by standard C. Neither are filenames, for that matter.
You're dead wrong.
I could quote the relevant section of the standard, but its more
instructive to leave you to find it yourself.
What filenames, other than those returned by tmpnam(), does the standard
guarantee refer to accessible files?
I found the relevant section myself.
C89, $4.9.3: The rules for composing valid file names are implementation-defined.
It would appear that I wasn't wrong after all. The only filenames a
strictly conformant program can use are those returned by tmpnam(),
which you can use up to 25 times, the minimum maximum TMP_MAX.
You know what?
You seem to have decided you don't like me, based on a week-long
conversation that you walked in on the end of and decided to respond
with smart-ass quips to every single one of my messages, even though i
had since changed my position. I'm not sure why I should dignify
anything you say to me with a response.
On 2005-11-21, Mark McIntyre <ma**********@spamcop.net> wrote: From what does your authority to start bullying everyone derive?
"bullying"?
All I did was question whether non-ISO-strict-c89-pure code was really
off-topic, as people claim. I've since dropped the subject, but now you
had to make it personal.
Who was i "bullying"? This thread has been closed and replies have been disabled. Please start a new discussion. |
