what parallel C language does MIPS Pro C Compiler support?
ram...@gmail.com
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
Walter Roberson
ram...@gmail.com <ram...@gmail.com> wrote:
> I need to write a parallel code in 'C' on the server that is
>running SGI Irix 6.5.
You should probably take this question to comp.sys.sgi.misc
>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.
No, the MIPSpro compilers do not support the Parallel C language.
>Or are there any other parallel C
>languages that have this feature?
[OT]
Here are some SGI links for you:
"MIPSpro Auto-Parallelizing Option Programmer's Guide"
You probably don't want to use that, though, as it is noticable
extra cost. It's useful when you first start out, but once you see
what kind of transformations it makes to your code, it is usually
easier to put in the directives manually.
"C Language Reference Manual"
"Chapter 10. Multiprocessing Directives"
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/CLanguageRef/sgi_html/ch10.html
"Chapter 11. Multiprocessing Advanced Features"
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/CLanguageRef/sgi_html/ch11.html
In other words, you can put the directives in manually.
Includes #pragma parallel, #pragma pfor, and #pragma synchronize .
These are not from different languages: they are all pragmas
that SGI uses to mark different aspects of parallel programming.
These are supported by SGI's C, and C++. SGI's F77 (Fortran 77)
multiprocessing directive support is documented at
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/MproF77_PG/sgi_html/apb.html
and F77's OpenMP directive support is documented at
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/MproF77_PG/sgi_html/ch05.html
The F90 (Fortran 90) OpenMP support is documented at
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/MPro7F90CD_RM/sgi_html/ch04.html
"Message Passing Toolkit: MPI Programmer's Manual"
"Message Passing Toolkit: PVM Programmer's Guide"
Various SGI system manual pages:
mpconf - multiprocessing configuration
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat3c/mpconf.z
sysmp - multiprocessing (and realtime) controls
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat2/standard/sysmp.z
pthreads - introduction to POSIX threads
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?cmd=getdoc&coll=0650&db=man&fname=5%20pthreads
--
I am spammed, therefore I am.
Peter Nilsson
> 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.
Neither does standard C.
http://www.ungerhu.com/jxh/clc.welcome.txt
--
Peter
Jordan Abel
That document does not claim to have the 'legal' status of a newsgroup
charter. Anyone know where the comp.lang.c charter can be found?
The best I can find online is
<ftp://ftp.uu.net/usenet/control/comp/comp.lang.c>
which contains a single-line description, "Discussion about C"
[When i look on google it looks like i'm opening a whole can of worms by
asking this, but it has to be said. Claims on a newsgroup that something
is forbidden as off-topic make an implicit claim that the charter says
so, which seems at best misleading and at worst dishonest.]
If clc doesn't have a charter, don't you think it needs one?
Simon Biber
Indeed, clc predates the introduction of newsgroup charters. It has
always got along fine without one. The regular posters define what is
allowable and not allowable.
--
Simon.
Keith Thompson
> On 2005-11-20, Peter Nilsson <ai...@acay.com.au> wrote:
>> ram...@gmail.com wrote:
>>> 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.
>>
>> Neither does standard C.
>>
>> http://www.ungerhu.com/jxh/clc.welcome.txt
>
> That document does not claim to have the 'legal' status of a newsgroup
> charter. Anyone know where the comp.lang.c charter can be found?
There is none.
[...]
> If clc doesn't have a charter, don't you think it needs one?
I'm not sure that it would be practical to create one and have it
accepted by -- well, by whoever would need to accept it for it to
become "official". We seem to have a general (though not universal)
consensus about what's topical.
--
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.
Mark McIntyre
<jma...@purdue.edu> wrote:
>On 2005-11-20, Peter Nilsson <ai...@acay.com.au> wrote:
>> ram...@gmail.com wrote:
>>> 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.
>>
>> Neither does standard C.
>>
>> http://www.ungerhu.com/jxh/clc.welcome.txt
>
>That document does not claim to have the 'legal' status of a newsgroup
>charter. Anyone know where the comp.lang.c charter can be found?
There isn't one - CLC predates the existence of the charter scheme.
The welcome message, FAQ, other regularly posted notes and topicality
guidelines provided by regulars constitute the equivalent of a
charter.
>The best I can find online is
><ftp://ftp.uu.net/usenet/control/comp/comp.lang.c>
>which contains a single-line description, "Discussion about C"
This is merely the group description.
>[When i look on google it looks like i'm opening a whole can of worms by
>asking this, but it has to be said. Claims on a newsgroup that something
>is forbidden as off-topic make an implicit claim that the charter says
>so, which seems at best misleading and at worst dishonest.]
You're mistaken. The nonexistence of a written consitution doesn't
prevent the group having one, any more than it prevented the UK from
having one for at least a millenium longer than CLC.
>If clc doesn't have a charter, don't you think it needs one?
No.
--
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 =----
Jordan Abel
> Jordan Abel wrote:
>> On 2005-11-20, Peter Nilsson <ai...@acay.com.au> wrote:
>>> http://www.ungerhu.com/jxh/clc.welcome.txt
>>
>>
>> That document does not claim to have the 'legal' status of a newsgroup
>> charter. Anyone know where the comp.lang.c charter can be found?
>>
>> The best I can find online is
>> <ftp://ftp.uu.net/usenet/control/comp/comp.lang.c>
>> which contains a single-line description, "Discussion about C"
>>
>> [When i look on google it looks like i'm opening a whole can of worms by
>> asking this, but it has to be said. Claims on a newsgroup that something
>> is forbidden as off-topic make an implicit claim that the charter says
>> so, which seems at best misleading and at worst dishonest.]
>>
>> If clc doesn't have a charter, don't you think it needs one?
>
> Indeed, clc predates the introduction of newsgroup charters.
And also that of Standard C.
Google's earliest clc message is dated 5 November 1986 - Though
ironically, it quotes a draft version of the standard, 86-017 to be
precise.
My question is, _why_ is only standard C on-topic. I got to thinking
about this because a recent crosspost between clc and comp.std.c seemed
to have the c.s.c-ers thinking that something [which is _clearly_
off-topic here] would be on-topic for clc, and, oddly, there was at
least one voice for the reverse [i.e. that the same thread would be
on-topic for csc and not clc]
which leaves open the question of just _WHERE_ such a thing _WOULD_ be
on-topic. I believe the specific issue was printf extensions.
> It has always got along fine without one. The regular posters define
> what is allowable and not allowable.
The problem is that without a _clear_ and _agreed-on_ definition of what
is allowed, you'll always have dissent. And is it really _right_ That
only "ISO Certified 98.99% Pure" topics should be discussed here? Who
decided that? Was it a consensus that people actually agreed on, or did
one person just make the claim and people assumed he was right, and it
has developed into a convention?
Kenny McCormack
Jordan Abel <jma...@purdue.edu> wrote:
...
>The problem is that without a _clear_ and _agreed-on_ definition of what
>is allowed, you'll always have dissent. And is it really _right_ That
>only "ISO Certified 98.99% Pure" topics should be discussed here? Who
>decided that? Was it a consensus that people actually agreed on, or did
>one person just make the claim and people assumed he was right, and it
>has developed into a convention?
Who just wandered into a mosque and asked "Why is Christianity O/T here?" ?
jacob navia
I am a regular poster here and I have a different view.
This group should discuss the C language, not a C ISO 89 subset.
This means that questions like extensions, new developments,
critics of the language, are on topic here.
Jordan Abel
I move that we have a vote. Someone post a RFD or something?
Walter Roberson
This is a really bad time to run an RFD. The entire RFD / CFV mechanism
is undergoing a -considerable- shakeup, and no RFDs are being
accepted for now (and possibly not for quite a number of months.)
The quick summary is that the people who administer the official
mechanisms at the moment want out and have announced their firm
commitment to resign, and are pushing for a complete rework of the
structure in order to have a viable organization to hand the reigns
over to. news.groups has the discussions.
--
Many food scientists have reported chocolate to be the single most
craved food. -- Northwestern University, 2001
Mark McIntyre
<jma...@purdue.edu> wrote:
>On 2005-11-20, Simon Biber <ne...@ralmin.cc> wrote:
>>
>> Indeed, clc predates the introduction of newsgroup charters.
>
>And also that of Standard C.
>
>My question is, _why_ is only standard C on-topic.
Its an interesting question. The answer is very simple - because that
what it is. There's no better answer, over the last 2 decades it has
generally been agreed that the purpose of CLC is to discuss the use of
standard C.
>I got to thinking
>about this because a recent crosspost between clc and comp.std.c seemed
>to have the c.s.c-ers thinking that something [which is _clearly_
>off-topic here] would be on-topic for clc, and, oddly, there was at
>least one voice for the reverse [i.e. that the same thread would be
>on-topic for csc and not clc]
Yes, there are sometimes things which do fall into that interesting
camp.
>The problem is that without a _clear_ and _agreed-on_ definition of what
>is allowed, you'll always have dissent.
The point you're missing is that it /does/ have a clear and agreed on
defintion. Its just not written down.
This isn't uncommon - I mentioned the constitution of the UK earlier.
We seem to have managed ok for several hundred years.
>And is it really _right_ That
>only "ISO Certified 98.99% Pure" topics should be discussed here? Who
>decided that? Was it a consensus that people actually agreed on, or did
>one person just make the claim and people assumed he was right, and it
>has developed into a convention?
Why do you actually need to know? The point is, the topic /is/
defined. If you want to change it, feel free to try.
Mark McIntyre
to the best of my knowledge, Jacob is in a minority of at best one, at
worst a handful, amongst the regulars.
>I move that we have a vote. Someone post a RFD or something?
Not interested.
If you want to change the topic, go form your own group, stop
buggering about with ones that have got along quite happily for
decades.
Malcolm
>
>> This group should discuss the C language, not a C ISO 89 subset.
>> This means that questions like extensions, new developments,
>> critics of the language, are on topic here.
>
> I move that we have a vote. Someone post a RFD or something?
>
Now we've got two developments. It has become obvious that C99 is unlikely
to ever be widely implemented, which changes the status of ANSI vis a vis
the language, and parallel programming is going to become a lot more
important in the near future.
Parallel programming will probably rejuvenate C because of the problems
inherent in trying to pass objects and other high-level data structures
between processes. That is something the newsgroup will probably welcome.
However exactly how to redefine topicality is a good question - there is no
point regs engaging in flame wars with each other about what is and what
isn't on-topic.
Mark McIntyre
<regn...@btinternet.com> wrote:
>
>However exactly how to redefine topicality is a good question - there is no
>point regs engaging in flame wars with each other about what is and what
>isn't on-topic.
The simplest solution is to create a new group comp.lang.nonstandard-c
or something like that. If it proves useful and informative, people
will move over to it, and CLC will die away. If it proves useless, and
uninformative people will return to CLC.
Bjørn Augestad
> On Sun, 20 Nov 2005 19:48:18 +0000 (UTC), in comp.lang.c , "Malcolm"
> <regn...@btinternet.com> wrote:
>
>> However exactly how to redefine topicality is a good question - there is no
>> point regs engaging in flame wars with each other about what is and what
>> isn't on-topic.
>
> 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?
Bjørn
[snip]
pete
>
> 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.
http://www.ungerhu.com/jxh/clc.welcome.txt
--
pete
Randy Howard
(in article
<dlqju1$24d$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>):
> For a long time it made perfect sense to discuss only ANSI C.
Or ISO C 90.
> Now we've got two developments. It has become obvious that C99 is unlikely
> to ever be widely implemented,
That's mostly because it offers almost nothing of value to
convince people to do the work to adopt it, and it directly
conflicts with widespread extensions, most notably those of gcc,
which means it was stillborn the day it was published, whether
they realized it at the time or not.
> which changes the status of ANSI vis a vis
> the language,
Forget about ANSI, it's not even in the picture anymore. Blame
the current state of affairs on ISO and lack of understanding of
how reality meets the dream of a standards group.
> and parallel programming is going to become a lot more
> important in the near future.
It already is, and has been for quite some time.
> Parallel programming will probably rejuvenate C because of the problems
> inherent in trying to pass objects and other high-level data structures
> between processes. That is something the newsgroup will probably welcome.
Parallel programming today pretty much ignores passing between
processes (unless on different systems over the wire), and
focuses on data use (and sharing) within a single process and
multiple threads. C with extensions is one way this is done
commonly, however if that is your bag, then you should be
discussing it in a forum filled with people that focus on it
actively, such as those in comp.programming.threads.
There is no reason to drag a group into that sort of discussion
when a better one already exists. Just as there is no reason to
discuss high end graphics programming here when there are better
forums.
Just as monolithic design is bad in most software engineering,
it's also bad in Usenet group scope. I suspect that more often
than not this desire to lump everything into clc is due to not
wanting to read multiple newsgroups rather than some well
thought out rational reason.
> there is no
> point regs engaging in flame wars with each other about what is and what
> isn't on-topic.
That much is certainly true.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Kenny McCormack
Mark McIntyre <markmc...@spamcop.net> wrote:
...
>Not interested.
>
>If you want to change the topic, go form your own group, stop
>buggering about with ones that have got along quite happily for
>decades.
Do you even come close to realizing how much like either a spoiled child
or, (worse) a religious fundie, you sound like?
Kenny McCormack
>or something like that. If it proves useful and informative, people
>will move over to it, and CLC will die away. If it proves useless, and
>uninformative people will return to CLC.
I think most of us see it the other way. That CLC is the logical name for
a newsgroup about discussion of C as practiced (in the real, sometimes
dirty, world, but always entertaining), while something like "clc.esoteric"
or "clc.pure" would be a reasonable thing for discussing the totally
useless but academically pure version that you seem to favor.
The point is that the name means something. People come here to discuss
real world C (imagine that - coming to a newsgroup named "comp.lang.c" to
discuss real world C) and are gobsmacked when they find out that the
natural obvious newsgroup name has been hijacked by a bunch of religious
loonies.
Keith Thompson
[...]
> Parallel programming today pretty much ignores passing between
> processes (unless on different systems over the wire), and
> focuses on data use (and sharing) within a single process and
> multiple threads. C with extensions is one way this is done
> commonly, however if that is your bag, then you should be
> discussing it in a forum filled with people that focus on it
> actively, such as those in comp.programming.threads.
That depends on the field, I suppose. On the systems I work with,
most of the parallelism involves cooperating processes running across
hundreds or thousands of nodes, with several CPUs per node -- and
sometimes across multiple sites. But this kind of thing is already
discussed in comp.parallel, comp.parallel.mpi, comp.sys.super, and
comp.distributed.
Since the mechanisms for doing this aren't part of the C language (for
example, you can use MPI from C, from Fortran, and probably from other
languages), it doesn't usually make much sense to discuss them in
comp.lang.c.
If parallism were ever added to the C language, of course it would
become topical in comp.lang.c. If you want to help make that happen,
comp.std.c might be a good place to start. I suspect the response
will be that it's unnecessary, since the add-on libraries already
exist, but you'rew welcome to try. (That's a generic "you", not
directed at anyone in particular.)
Jordan Abel
> 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. Not only has it not been
written down, it has never been subject to a vote.
Richard Heathfield
> I think most of us see it the other way. That CLC is the logical name for
> a newsgroup about discussion of C as practiced (in the real, sometimes
> dirty, world, but always entertaining),
Right. And in the real world, C is quite often selected because of its
astonishingly high level of portability.
> while something like
> "clc.esoteric" or "clc.pure" would be a reasonable thing for discussing
> the totally useless but academically pure version that you seem to favor.
Totally useless it may be, but it pays the mortgage for a very large number
of people.
> The point is that the name means something.
Indeed it does:
comp -> computing
lang -> language
c -> C
Nothing in there about MIPS, Windows, Linux, threads, sockets, or all the
rest of it. Just C.
--
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)
Randy Howard
(in article <lny83i6...@nuthaus.mib.org>):
> Randy Howard <randy...@FOOverizonBAR.net> writes:
> [...]
>> Parallel programming today pretty much ignores passing between
>> processes (unless on different systems over the wire), and
>> focuses on data use (and sharing) within a single process and
>> multiple threads. C with extensions is one way this is done
>> commonly, however if that is your bag, then you should be
>> discussing it in a forum filled with people that focus on it
>> actively, such as those in comp.programming.threads.
>
> That depends on the field, I suppose. On the systems I work with,
> most of the parallelism involves cooperating processes running across
> hundreds or thousands of nodes, with several CPUs per node -- and
> sometimes across multiple sites.
Of course, fair point. I was thinking of fork() and friends
when I wrote that, and completely forgot to mention parallel in
the sense you did. Probably because I have spent a lot of time
writing pthread code in recent years, and almost zero time
writing MPI code.
> But this kind of thing is already
> discussed in comp.parallel, comp.parallel.mpi, comp.sys.super, and
> comp.distributed.
Indeed.
Rouben Rostamian
CLC is an excellent resource but in my opinion it can benefit
from a name change -- something like comp.lang.c.iso will
reflect better its purpose and help reduce the incessant
discussions of topicality and lynching of newbies.
To address your question of how the current rules were
developed, the following allegory explains it very well.
I don't mean it in the way of disrespect to any readers
of this group. I don't remember where I got it; it's
not /my/ translation.
--
Rouben Rostamian
----------------------------------------------------------------------
From: "De banaan wordt bespreekbaar", cultuurverandering in
ambtelijk en politiek Groningen. door Tom Pauka en
Rein Zunderdorp (Nijgh en van Ditmar, 1988)
Translated: "The banana becomes open to discussion", cultural changes
in administrative and political Groningen (city in Netherlands) by
Tom Pauka and Rein Zunderdorp (Nijgh and van Ditmar, 1988)]
Take a cage with apes. In the cage we hang a banana on a string,
and put stairs under it. Before long an ape goes to the stairs
towards the banana, but as soon as it even touches the stairs,
all apes are sprayed with water. After a while the same ape or
another one makes another attempt, with the same result: all
apes are sprayed. If later another ape tries to climb the
stairs, the others will try to prevent it.
Now we take one ape from the cage and put in a new one. The new
ape sees the banana, and wants to climb the stairs. To his
horror all other apes attack him. After another attempt he
knows: if he wants to climb the stairs, he is beaten up. Then we
remove a second ape and replace it by another new one. The
newcomer goes to the stairs and gets beaten up. The previous
new ape takes part in the punishment with enthusiasm.
A third old ape is replaced by a third new one. The new one
makes it to the stairs and get beaten up as well. Two of the
apes who beat him, have no idea why you may not climb the stairs.
We replace the fourth old ape, and the fifth, etc. until all
apes which have been sprayed with water have been replaced.
Nevertheless, no ape ever tries to climb the stairs.
"But Sir, why not?"
"Because that's the way we do things here, lad."
Peter Nilsson
> ...
> My question is, _why_ is only standard C on-topic.
Because there are (waving hands) 50 million groups around that already
discus
non-standard C. What is the point of sacrificing clc just to gain
another one of
those groups?
--
Peter
Jordan Abel
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?
This newsgroup's charter is not in writing and has never been subject to
a vote. From what does its authority derive?
pete
> 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.
--
pete
Jordan Abel
Mob rule requires a vote.
pete
Where did you get the idea
that the topic of this newsgroup
isn't exactly what you want it to be?
--
pete
Richard Heathfield
Presumably this is a reference to the word "democracy". As we all know,
democracy is "one man, one vote". Well, I'm the man with the vote, and I
vote we stick to ISO C. :-)
In fact, though, the authority of this group derives from the expertise of
those who contribute to it. If you successfully change the function of the
group, it will almost certainly lead to the loss to the Usenet community of
much of that expertise.
As someone else rightly said elsethread, what is to be gained by turning
over comp.lang.c to implementation-specific issues? Are these issues not
already amply catered for by groups such as comp.unix.programmer,
comp.os.linux.development.apps, comp.os.ms-windows.programmer.win32, and so
on?
Jordan Abel
> Jordan Abel said:
>
> Presumably this is a reference to the word "democracy". As we all know,
> democracy is "one man, one vote". Well, I'm the man with the vote, and I
> vote we stick to ISO C. :-)
Recount! [j/k]
> In fact, though, the authority of this group derives from the expertise of
> those who contribute to it. If you successfully change the function of the
> group, it will almost certainly lead to the loss to the Usenet community of
> much of that expertise.
This comes from the still unproven presumption that a majority would
leave if people stopped whining about something that is, according to
any actual description in writing of the newsgroup, and any reasonable
interpretation of "comp.lang.c" given no pre-existing information,
on-topic, being "off-topic"
> As someone else rightly said elsethread, what is to be gained by turning
> over comp.lang.c to implementation-specific issues?
that's not what i said and you know it. All i'm asking is for people to
stop whining about stuff being off-topic if they have no basis for it.
> Are these issues not
> already amply catered for by groups such as comp.unix.programmer,
> comp.os.linux.development.apps, comp.os.ms-windows.programmer.win32, and so
> on?
You are so asking for a smart-ass "Correct. they're not."
Richard Heathfield
> On 2005-11-21, Richard Heathfield <inv...@invalid.invalid> wrote:
>> Jordan Abel said:
>>
>> Presumably this is a reference to the word "democracy". As we all know,
>> democracy is "one man, one vote". Well, I'm the man with the vote, and I
>> vote we stick to ISO C. :-)
>
> Recount! [j/k]
Okay. Recount complete. Result unchanged.
>> In fact, though, the authority of this group derives from the expertise
>> of those who contribute to it. If you successfully change the function of
>> the group, it will almost certainly lead to the loss to the Usenet
>> community of much of that expertise.
>
> This comes from the still unproven presumption that a majority would
> leave if people stopped whining about something that is, according to
> any actual description in writing of the newsgroup, and any reasonable
> interpretation of "comp.lang.c" given no pre-existing information,
> on-topic, being "off-topic"
It's hardly an unproven presumption. Look what happened to comp.lang.c++
when they relaxed their topicality rules. The place basically fell apart.
It took a lot of work to turn it back into a useful group.
>> As someone else rightly said elsethread, what is to be gained by turning
>> over comp.lang.c to implementation-specific issues?
>
> that's not what i said and you know it.
Well, I'm not trying to put words into your mouth; I'm merely responding to
your point about "authority", in the context of your earlier statement, "My
question is, _why_ is only standard C on-topic."
> All i'm asking is for people to
> stop whining about stuff being off-topic if they have no basis for it.
It seems to me that the original question in this thread was a reasonable
question to ask here, and that the answer "it's off-topic" is a reasonable
answer too, albeit not as helpful as Walter Roberson's reply which
mentioned a more suitable newsgroup.
>> Are these issues not
>> already amply catered for by groups such as comp.unix.programmer,
>> comp.os.linux.development.apps, comp.os.ms-windows.programmer.win32, and
>> so on?
>
> You are so asking for a smart-ass "Correct. they're not."
Please moderate your language; this is a family show. Thanks. If those other
groups are indeed inadequately serving the needs of their users despite
being dedicated to their platforms, how much more inadequately comp.lang.c
would serve those needs! The lack of experts in a particular group does not
imply that some other group will have more experts in the field covered by
that group. And if those other groups /are/ adequately serving the needs of
their users, the point is academic anyway.
Jack Klein
<jma...@purdue.edu> wrote in comp.lang.c:
> On 2005-11-20, Simon Biber <ne...@ralmin.cc> wrote:
> > Jordan Abel wrote:
> >> On 2005-11-20, Peter Nilsson <ai...@acay.com.au> wrote:
> >>> http://www.ungerhu.com/jxh/clc.welcome.txt
> >>
> >>
> >> That document does not claim to have the 'legal' status of a newsgroup
> >> charter. Anyone know where the comp.lang.c charter can be found?
> >>
> >> The best I can find online is
> >> <ftp://ftp.uu.net/usenet/control/comp/comp.lang.c>
> >> which contains a single-line description, "Discussion about C"
> >>
> >> [When i look on google it looks like i'm opening a whole can of worms by
> >> asking this, but it has to be said. Claims on a newsgroup that something
> >> is forbidden as off-topic make an implicit claim that the charter says
> >> so, which seems at best misleading and at worst dishonest.]
> >>
> >> If clc doesn't have a charter, don't you think it needs one?
> >
> > Indeed, clc predates the introduction of newsgroup charters.
>
> And also that of Standard C.
>
> Google's earliest clc message is dated 5 November 1986 - Though
> ironically, it quotes a draft version of the standard, 86-017 to be
> precise.
>
> My question is, _why_ is only standard C on-topic. I got to thinking
> about this because a recent crosspost between clc and comp.std.c seemed
> to have the c.s.c-ers thinking that something [which is _clearly_
> off-topic here] would be on-topic for clc, and, oddly, there was at
> least one voice for the reverse [i.e. that the same thread would be
> on-topic for csc and not clc]
>
> which leaves open the question of just _WHERE_ such a thing _WOULD_ be
> on-topic. I believe the specific issue was printf extensions.
>
> > It has always got along fine without one. The regular posters define
> > what is allowable and not allowable.
>
> The problem is that without a _clear_ and _agreed-on_ definition of what
> is allowed, you'll always have dissent. And is it really _right_ That
> only "ISO Certified 98.99% Pure" topics should be discussed here? Who
> decided that? Was it a consensus that people actually agreed on, or did
> one person just make the claim and people assumed he was right, and it
> has developed into a convention?
I have no proof, but your question makes me think that you are
relatively new to usenet.
I've been here for a while, and I've seen good groups destroyed by
being swamped by off-topic posts.
It was perhaps five or six years ago that comp.lang.c++ was nearly
destroyed by becoming yet another Visual C++/Windows programming
group. I know I stopped reading and participating, and quite a few of
the more knowledgeable regulars disappeared as well. It was only by
the determined effort of a group of regulars that the group was saved.
Is it really _right_? I think so, and I'll tell you why. Literally
some of the most knowledgeable experts on C and C++ in the world help
others on comp.lang.c and comp.lang.c++. That includes, not
infrequently, members of the language standards committees. There is
plenty of historical evidence that these are the first to leave when a
group gets polluted by too much off-topic material.
These groups are far too valuable as resources to be spoiled. For
every poster who whines that "you can't write a real world program in
standard C (or C++)", there are many more who realize that you can't
write any program at all in C or C++ without using standard C or C++,
and usually far more than you use any extensions or third party
library.
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.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Jack Klein
<ja...@jacob.remcomp.fr> wrote in comp.lang.c:
> I am a regular poster here and I have a different view.
>
> This group should discuss the C language, not a C ISO 89 subset.
But how do you define "the C language"? By what you want it to be? By
what I want it to be? By what Microsoft wants it to be? In technical
discussions, a term without a precise definition is meaningless.
There is one internationally recognized definition of "the C
language". It has been ratified by several international standards
organizations, and the national standards bodies of most of the
nations most involved in computer programming.
So we don't have to accept your definition, or mine, we have an
objective standard definition to point to.
> This means that questions like extensions, new developments,
> critics of the language, are on topic here.
--
Keith Thompson
[...]
A good analogy, if you replace "the ape is beaten up" with "the ape is
told where to find another cage where he can get his bananas".
Bjørn Augestad
> 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.
Bjørn
Dik T. Winter
...
> Google's earliest clc message is dated 5 November 1986 - Though
> ironically, it quotes a draft version of the standard, 86-017 to be
> precise.
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'.
> The problem is that without a _clear_ and _agreed-on_ definition of what
> is allowed, you'll always have dissent. And is it really _right_ That
> only "ISO Certified 98.99% Pure" topics should be discussed here? Who
> decided that? Was it a consensus that people actually agreed on, or did
> one person just make the claim and people assumed he was right, and it
> has developed into a convention?
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.
--
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
> Jordan Abel said:
>> This comes from the still unproven presumption that a majority would
>> leave if people stopped whining about something that is, according to
>> any actual description in writing of the newsgroup, and any reasonable
>> interpretation of "comp.lang.c" given no pre-existing information,
>> on-topic, being "off-topic"
>
> It's hardly an unproven presumption. Look what happened to comp.lang.c++
> when they relaxed their topicality rules. The place basically fell apart.
> It took a lot of work to turn it back into a useful group.
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.
>> You are so asking for a smart-ass "Correct. they're not."
>
> 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...]
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.
Jordan Abel
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]
Simon Biber
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.
--
Simon.
Kenny McCormack
Jordan Abel <jma...@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]
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.
Jordan Abel
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.
--
But, then, you're a troll.
Richard Heathfield
> On 2005-11-21, Richard Heathfield <inv...@invalid.invalid> wrote:
>> Jordan Abel said:
>>> This comes from the still unproven presumption that a majority would
>>> leave if people stopped whining about something that is, according to
>>> any actual description in writing of the newsgroup, and any reasonable
>>> interpretation of "comp.lang.c" given no pre-existing information,
>>> on-topic, being "off-topic"
>>
>> It's hardly an unproven presumption. Look what happened to comp.lang.c++
>> when they relaxed their topicality rules. The place basically fell apart.
>> It took a lot of work to turn it back into a useful group.
>
> 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.
Richard Heathfield
> 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.
Jordan Abel
>
>> 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.
Lew Pitcher
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-----
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
Kenny McCormack
>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.
Kenny McCormack
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.
Jordan Abel
> Jordan Abel <jma...@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]
Randy Howard
(in article <O-qdnYiR3dW...@telenor.com>):
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
Richard Bos
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
Randy Howard
(in article <slrndo3er8....@random.yi.org>):
> On 2005-11-21, Jack Klein <jack...@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
(in article <slrndo3j4p....@random.yi.org>):
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.
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.
Jordan Abel
> (in article <slrndo3j4p....@random.yi.org>):
>
>> On 2005-11-21, Lew Pitcher <Lew.P...@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.
Randy Howard
(in article <slrndo3lf9....@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
(in article <slrndo3lco....@random.yi.org>):
> On 2005-11-21, Randy Howard <randy...@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.
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
> On 2005-11-21, Dik T. Winter <Dik.W...@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.
Richard Heathfield
> On 2005-11-21, Richard Heathfield <inv...@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? :-)
Jordan Abel
> Jordan Abel said:
>
>> On 2005-11-21, Richard Heathfield <inv...@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]
Bjørn Augestad
> Bjørn Augestad wrote
> (in article <O-qdnYiR3dW...@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
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 (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.
Keith Thompson
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
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
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
> Jordan Abel <jma...@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
Jordan Abel
> 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.
Randy Howard
(in article <2pCdnWuatoG...@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
(in article <lnveyl3...@nuthaus.mib.org>):
> Randy Howard <randy...@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. :-)
jacob navia
> 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???
Richard Heathfield
> 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
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?
>
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.
jacob navia
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
(in article <43822de6$0$6653$8fcf...@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.
jacob navia
> 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.
jacob navia
>
> 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.
Jordan Abel
> 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.
Michael Mair
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.
Walter Roberson
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
Keith Thompson
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.
Randy Howard
(in article <43823bdb$0$6686$8fcf...@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?
Chris Torek
>> 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 <43823ab0$0$29199$8fcf...@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()?
Mark McIntyre
<jma...@purdue.edu> wrote:
>On 2005-11-20, Mark McIntyre <markmc...@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 =----
Mark McIntyre
<jma...@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
<jma...@purdue.edu> wrote:
>On 2005-11-21, pete <pfi...@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
<jma...@purdue.edu> wrote:
>On 2005-11-21, Jack Klein <jack...@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
<jma...@purdue.edu> wrote:
>
>How about subject flags
How about you just bugger off?
Mark McIntyre
<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
<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
<jma...@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
<jma...@purdue.edu> wrote:
>On 2005-11-21, Kenny McCormack <gaz...@yin.interaccess.com> wrote:
>> In article <slrndo3f6d....@random.yi.org>,
>> Jordan Abel <jma...@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.
Keith Thompson
> On Mon, 21 Nov 2005 02:00:33 +0000 (UTC), in comp.lang.c , Jordan Abel
> <jma...@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.
Jordan Abel
> On Mon, 21 Nov 2005 21:35:40 +0000 (UTC), in comp.lang.c , Jordan Abel
> <jma...@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.
Jordan Abel
> 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"?