Criticisms?

[Zach]

Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:

http://en.wikipedia.org/wiki/Critici...mming_language

Zach

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>Chris Hills <ch***@phaedsys.orgwrites:
[...]

>I can not see any justification for discussion ANSI C 89 or the
original K&R (both of which are obsolete) but not C as currently used.
There are a few holier than thou pedants on there who want to
artificially restrict the NG to a sub set of C that most do not
use. But then pointlessly widen it to various obsolete versions of the
standard.

[...]

Perhaps we can have this discussion without insulting other
participants.

Only those that deserve it.

[Richard Harter]

On 22 Jan 2007 17:22:19 -0800, Keith Thompson <ks***@mib.orgwrote:

>ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>Extensions provided by lcc-win32 can be discussed in
comp.compilers.lcc. Extensions provided by gcc can be discussed in
the various gcc newsgroups. And so on.

That might be appropriate when first implementing an extension, but
surely there is scope for discussions that are neither limited to a
single implementation nor proposed for standardisation?

I've modified the subject header, since the discussion seems to be
veering in a new direction.

The general (though not universal) consensus in this newsgroup is, and
has been for a long time, that compiler-specific extensions are
off-topic. It's not *quite* that simple; for example, discussion of
the fact that the standard permits extensions, and of the restrictions
it places on them for a conforming implementation, is topical. But a
detailed discussion of, say, gcc's syntax for inline assembly
language, or of functions specified by POSIX but not by the C
standard, is not.

If there's a proposal to alter the (somewhat informal) topicality
guidelines, I'd have no problem discussing that, though I'd personally
oppose any major changes. I can't think of a simple set of guidelines
that would permit discussion of the C-like language implemented by,
for example, lcc-win32, but would not permit discussion of the C-like
language known as C++.

Note that both lcc and gcc have their own newsgroups. Other
implementations may not, but the lack of an appropriate forum is not
the resposibility of this one.

(Meta-discussions about topicality, such as this one, are
traditionally considered to be topical.)

Once upon a time comp.lang.c was the appropriate venue for discussing
proposed changes to C. As a practical matter it no longer is because
there is are a number of regulars who quite adamantly insist that such
discussions are off topic. Perhaps it would be better to have a
newsgroup specifically discussing the C language including possible
extensions or revisions. Many newsgroups have a .d subgroup.

[Spiros Bousbouras]

Chris Hills wrote:

In article <ep***********@pc-news.cogsci.ed.ac.uk>, Richard Tobin
<ri*****@cogsci.ed.ac.ukwrites

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>Standard C doesn't support operator overloading. If you want to
discuss some language that does, find a newsgroup for that language.
If you want to advocate adding operator overloading to a future C
standard, take it to comp.std.c.

That seems to imply that there's no newsgroup for discussing possible
extensions to C unless you want to talk about standardising them,
which is a bit unfortunate,

I agree. No compiler AFAIK is normally used in PURE Standard C mode
because none of them fully implement C99.

Jacob Navia himself has given examples of several compilers
which fully implement C99. Furthermore several participants
here have stated that they often use their compilers in pure
C89 mode.

When you query that here with
the pedants they say this ng is for:

Who are "the pedants" ? Do you plan to present
any argument that they are indeed pedants ? Is it
even relevant to your main point ?

If the answer to the last 2 questions is no then perhaps
you could consider the possibility that avoiding characterizations
of persons will lead to more constructive discussion. I'm sure you
can present whatever arguments you have against any opinion
without going into whether those who support the opinion
are pedants or not.

>
K&R C, K&R C2, ANSI C 89, ISO C 90, C95/6 C99 or any other version of
the C standard no mater how obsolete.

basically any version of the C standard from K&R C onwards but not C as
actually used by 90% of the C community.

Could you give some description of what kind of C
the 90% of the C community uses ? If you mean that
90% uses some extensions to C then it may well be true
(actually if we count as extensions one's personal libraries
then the figure probably is 99.99%) but different people
will use different extensions. What is it that you propose
we discuss here ?

I can not see any justification for discussion ANSI C 89 or the original
K&R (both of which are obsolete) but not C as currently used.

If people are still writing C89 programmes then I don't consider
the C89 standard obsolete. One popular compiler is gcc and C89 is
the only standard which it fully supports so far.

There
are a few holier than thou pedants on there who want to artificially
restrict the NG to a sub set of C that most do not use. But then
pointlessly widen it to various obsolete versions of the standard.

If you want to discuss Standard C it should be ISO C99 and probably ISO
C 95 (as the previous and most widley used version) not all the other
obsolete versions from over a decade or two ago.

I don't see why the older standards shouldn't be discussed if
people are still using them. Basically I feel that any kind of C
people use should be discussed in some group. The question
is how to organize things , meaning divide all the huge number
of possible topics to discuss , amongst groups so that people
can find relatively easily the information they're looking for and
also the subscribers to each group mostly get to see only material
which is useful and interesting to them. I do not intend to propose
a general scheme but I certainly feel that there ought to be a group
which specializes in C according to the various standards over
the decades. It just so happens that this is this group.

Nor the local BSI, DIN
ANSI versions they are not the International Standard.

It is discussions like "overloading C" that lead to the extensions of
the language. Some make it into the ISO standard some don't .

as in a language as mature as C extensions
should be experimented with long before standardisation is considered.
comp.lang.c seems like the most natural home for such discussions.

I agree.

I agree too.

I don't mind extensions to the language being discussed
here. But if someone proposes an extension to the language
he should write some sort of article or essay explaining
what exactly it is that he proposes , why he feels the extension
would be useful , any case studies or even personal experience
which exhibit this usefulness plus one other very important condition:
*** That the proposed extension will not change the ***
*** philosophy of the language. ***

The reason that I'm adding this condition is that I want
to avoid an endless stream of posts saying something like:
"Wouldn't it be cool if C had such and such feature ?"

Doh , of course it would be cool. That's why there are so
many languages available apart from C , because people
came up with all kinds of useful features they would
like a programming language to have. But the success and
continuing use of C clearly shows that there are plenty of
people who like the C philosophy. If anyone wants a language
with a different philosophy they can always create it but I
don't see any reason why they would want to extinguish the
already existing philosophy which so many people like. If one
doesn't like the C philosophy noone forces them to use it.
Now , obviously different people will have different ideas
about what the C philosophy is. So my point is that in the
article where one proposes their extension they should also
explain what they consider the philosophy of C to be and
why their extension won't change this philosophy.

By the way , it is philosophy which characterizes a language
not the name. If for any reason C were to be replaced by
some language with the same name but different philosophy
then C will have died.
For me two essential features of the C philosophy are
portability and "no generated machine instructions unless
the programmer asked for them in the source".

So for example I'm against automatic checking of array
bounds (ACAB) because it would mean additional overhead.
Perhaps the language could support it as an option but it
should be possible to turn it off. I'm not denying that ACAB
is a very useful feature and it may be that in the majority
of projects the additional overhead wouldn't matter but for
those cases where it would matter or where one feels certain,
for whatever reasons, that array bounds won't be violated even
without the checking , I feel that there should be available a
portable high level language where the compiler wouldn't
automatically add the additional overhead. Such a language
does exist and it is called C. This ought to remain.

[Default User]

Richard Tobin wrote:

In article <ep**********@news.xmission.com>,
Kenny McCormack <ga*****@xmission.xmission.comwrote:

You're not from here, is you?

I've been here, on and off, for 20 years.

You have to figure where "here" is. I think Kenny is from some other
planet.


Brian

[CBFalconer]

Default User wrote:

Richard Tobin wrote:

>Kenny McCormack <ga*****@xmission.xmission.comwrote:

>>You're not from here, is you?

I've been here, on and off, for 20 years.

You have to figure where "here" is. I think Kenny is from some
other planet.

Well, since men and women have used up Mars and Venus as origins,
that pretty well leaves Mercury and Jupiter. Possibly some minor
asteroid also. Maybe it'll go back.

--
"The mere formulation of a problem is far more often essential
than its solution, which may be merely a matter of mathematical
or experimental skill. To raise new questions, new possibilities,
to regard old problems from a new angle requires creative
imagination and and marks real advances in science."
-- Albert Einstein

[Richard Heathfield]

jacob navia said:

Richard Tobin a écrit :

<snip>

>Just because something might, if successful, be considered in a future
standard, that doesn't mean that comp.std.c is the appropriate place
to discuss it now. Language design isn't standardisation, nor is it
necessarily compiler-specific. If people want to ask questions about,
say, how to use lcc's extensions, then an lcc group is appropriate.
But if they want to discuss whether such extensions are a good idea,
or how they might be done differently, then comp.lang.c is a good
place.

Exactly.

And the arguments I have heared are (mostly) that it is
off topic, non portable, can't discuss it here blah blah blah...

That sounds more like Kenny McCormack than Jacob Navia (perhaps they are the
same person? It wouldn't surprise me). But of course it *is* off-topic. It
*is* non-portable. More to the point, it *is not C*.

We *could* discuss it here - but we choose not to, because it's off-topic.
Here, we discuss the C language, not Fairyland. If someone wishes to
propose extensions to the language, that is their right, but the place to
do it is in comp.std.c, where changes to the Standard are discussed.

The extensions I propose are intended for the C language as a whole.

Let us trust, then, that the committee has more sense than to take those
proposals on board.

The implementation in lcc is just to prove that their implementation
is very easy and doesn't have any particular difficulty.

Ease of implementation is *not* the issue here.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

jacob navia said:

<snip>

The crux of the matter is just to hire those wonderful
programmers (that are here in abundance as it seems) that
are "competent" and never in their career have had a
memory overwrite or a array out of bounds indexing
error.

You have many times misrepresented the "take care" argument as an "I'm
perfect" argument. This has been pointed out a number of times. As far as I
can tell, you've never tried to deny that you are misrepresenting that
argument, so presumably you know you're doing it.

Clearly, then, you are not interested in the truth. It seems you are not
interested in your reputation, either (since almost every article you post
has only a negative effect thereon). So I'm curious - why *do* you post to
comp.lang.c? Is it the money?

And actual FACTS like the total loss of Mars Global Surveyor
because of a memory overwrite will be dismissed as the
fact of an "incompetent" programmer. NASA has a lot of them
as it seems...

I'm sure NASA has its fair share of incompetent programmers. This one sounds
like careless programming combined with careless testing combined with
tight schedule. Yes, it happens. (Presumably this bug could have been
picked up with a tool such as Electric Fence, had anyone thought to use
it.)

This is a similar situation when I pointed out to the problems
of using p = malloc(n*sizeof(*p)).

Just because you see a problem, that doesn't mean the problem actually
exists.

The same people starting
arguing that there isn't any UB (because overflow is
well defined for unsigned

No, it isn't. Overflow *doesn't exist* for unsigned integers.

even if the result is mathematically wrong).

No, it isn't. There's more to mathematics than you realise.

And the "incompetent programmer" came up again. Nothing
was said that the language doesn't have anything to test overflow!

There is no such thing as overflow for unsigned integer types.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:
[...]

We *could* discuss it here - but we choose not to, because it's off-topic.
Here, we discuss the C language, not Fairyland. If someone wishes to
propose extensions to the language, that is their right, but the place to
do it is in comp.std.c, where changes to the Standard are discussed.

One of the classes of discussion being debated, I think, is extensions
that are *not* necessarily being advocated for addition to the
standard (after all, if it's in the standard, then it's not an
extension), particularly such extensions that are not
compiler-specific or OS-specific.

I'm not convinced that this is a non-empty set, though.

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

[santosh]

Keith Thompson wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:
[...]

We *could* discuss it here - but we choose not to, because it's off-topic.
Here, we discuss the C language, not Fairyland. If someone wishes to
propose extensions to the language, that is their right, but the place to
do it is in comp.std.c, where changes to the Standard are discussed.

One of the classes of discussion being debated, I think, is extensions
that are *not* necessarily being advocated for addition to the
standard (after all, if it's in the standard, then it's not an
extension), particularly such extensions that are not
compiler-specific or OS-specific.

I'm not convinced that this is a non-empty set, though.

Yes, offhand, I can't think of any compiler agnostic extension/s, that
aren't considered suitable for future standardisation.

Maybe fflush(stdin) is a possible candidate?

[Richard Bos]

cr*@tiac.net (Richard Harter) wrote:

On 22 Jan 2007 17:22:19 -0800, Keith Thompson <ks***@mib.orgwrote:

The general (though not universal) consensus in this newsgroup is, and
has been for a long time, that compiler-specific extensions are
off-topic. It's not *quite* that simple; for example, discussion of
the fact that the standard permits extensions, and of the restrictions
it places on them for a conforming implementation, is topical. But a
detailed discussion of, say, gcc's syntax for inline assembly
language, or of functions specified by POSIX but not by the C
standard, is not.

Once upon a time comp.lang.c was the appropriate venue for discussing
proposed changes to C. As a practical matter it no longer is because
there is are a number of regulars who quite adamantly insist that such
discussions are off topic.

Actually, I think such discussions would still be on-topic. Note:
_discussing_ _proposed_ changes to C. _Not_ plugging, again and again
and again, your own embraced-and-extended almost-C implementation, and
insulting real C because it doesn't have Your Favourite Toy Extension.
There's quite a large gap, there.

Richard

[pete]

Richard Bos wrote:

>
cr*@tiac.net (Richard Harter) wrote:

Once upon a time comp.lang.c
was the appropriate venue for discussing
proposed changes to C.

Actually, I think such discussions would still be on-topic.

Especially on comp.std.c

--
pete

[atv]

On 2007-01-19 12:28:03 +0100, Richard Heathfield <rj*@see.sig.invalidsaid:

>>

>What it would do is allow beginners to write

#include <stdio.h>

int main(void)
{
int degrees_c;
scanf("%d", &degrees_c);
printf("...is %d in Fahrenheit.\n", (degrees_c * 9) / 5 + 32);
}

without writing something that is as undefined as, say, using gets.
We all know that this program is safer than one that uses gets, but
the standard does not say so and, to use your version of UB, nuclear
war may result from running it.

I hope that beginners would not write code like that, but I know that
they do. Yes, the program is safer than one containing a call to gets.
Nevertheless, it fails to check whether the degrees_c object has been
correctly populated, and it fails to check for overflow possibilities
before performing the multiplication.

Ok, i'm just wondering, how many people actually check for something
like 'the proper populating
of degrees_c, and conversion overflow (i didn't even think of that).
Seriously, i really would like
to know, because i've never seen any book or manual advocating this.

Again, is this something i should be concerned about or is this only
applicable for safe based software (read NASA). It would probably add
some lines to my code. Aren't these issues which
the compiler should take care off and error out if these criteria
aren't satisfied ?

I hope i misunderstood the above. In that case, just ignore me :-)
-alef

[santosh]

atv wrote:

On 2007-01-19 12:28:03 +0100, Richard Heathfield <rj*@see.sig.invalidsaid:

What it would do is allow beginners to write

#include <stdio.h>

int main(void)
{
int degrees_c;
scanf("%d", &degrees_c);
printf("...is %d in Fahrenheit.\n", (degrees_c * 9) / 5 + 32);
}

without writing something that is as undefined as, say, using gets.
We all know that this program is safer than one that uses gets, but
the standard does not say so and, to use your version of UB, nuclear
war may result from running it.

I hope that beginners would not write code like that, but I know that
they do. Yes, the program is safer than one containing a call to gets.
Nevertheless, it fails to check whether the degrees_c object has been
correctly populated, and it fails to check for overflow possibilities
before performing the multiplication.

Ok, i'm just wondering, how many people actually check for something
like 'the proper populating
of degrees_c, and conversion overflow (i didn't even think of that).
Seriously, i really would like
to know, because i've never seen any book or manual advocating this.

Truthfully not many. Books have only so much space, so often,
especially the tutorial types tend to trade-off bullet-proofing their
code, in favour of clarity and conciseness.

Again, is this something i should be concerned about or is this only
applicable for safe based software (read NASA). It would probably add
some lines to my code.

Unless, you're under special constraints, adding checks is always
recommendable.

Aren't these issues which
the compiler should take care off and error out if these criteria
aren't satisfied ?

As far as the C language is concerned, no. It has always been the
philosophy of the language to not get in the way of the knowledgeble
programmer. If you want lots of built-in automatic checking then C is
certainly not the language for you.

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

>
There is no such thing as overflow for unsigned integer types.

If you want to be pedantic about it, C offers a system modulus INT_MAX + 1.

Personally I would happily trade the free modulus op for an infinite int, or

a 64 bit int

which is almost as good. Integers usually count something, and you get a lot
of things in 64 bits.

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

There is no such thing as overflow for unsigned integer types.

If you want to be pedantic about it, C offers a system modulus INT_MAX + 1.

If you want to be pedantic, it's UINT_MAx + 1 (or the appropriate
constant for whatever type you're using).

Personally I would happily trade the free modulus op for an infinite int, or

a 64 bit int

which is almost as good. Integers usually count something, and you get a lot
of things in 64 bits.

Types long long and unsigned long long are guaranteed to be at least
64 bits; there's no need to change the definition of type int. And
there are libraries that support arbitrary-precision integers (if they
were built into the language, the compiler would have to generate
calls to such a library anyway).

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

On Tue, 23 Jan 2007 14:26:51 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Jacob talks fancier stuff, "future and present of C language".

Right, and this is topical for comp.std.c, provided the proposer
doesn't start off by annoying and alienating the regulars there by
persistent rudeness or paranoia.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Cesar Rabak]

Keith Thompson escreveu:
[snipped]

>
In this case, one poster insists on discussing a specific extension
(operator overloading) implemented in a single compiler. I haven't
seen him or anyone else advocating that it be implemented in other
compilers, except possibly as a future standard feature.

Interesting. My reading differs from yours. Each time the _possibility_
of adding this to the C (Standard) language is mentioned he is flamed
before can follow...

just my 0.0199999....

[Richard Harter]

On Wed, 24 Jan 2007 15:42:00 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:

>cr*@tiac.net (Richard Harter) wrote:

>On 22 Jan 2007 17:22:19 -0800, Keith Thompson <ks***@mib.orgwrote:

>The general (though not universal) consensus in this newsgroup is, and
has been for a long time, that compiler-specific extensions are
off-topic. It's not *quite* that simple; for example, discussion of
the fact that the standard permits extensions, and of the restrictions
it places on them for a conforming implementation, is topical. But a
detailed discussion of, say, gcc's syntax for inline assembly
language, or of functions specified by POSIX but not by the C
standard, is not.

>Once upon a time comp.lang.c was the appropriate venue for discussing
proposed changes to C. As a practical matter it no longer is because
there is are a number of regulars who quite adamantly insist that such
discussions are off topic.

Actually, I think such discussions would still be on-topic. Note:
_discussing_ _proposed_ changes to C. _Not_ plugging, again and again
and again, your own embraced-and-extended almost-C implementation, and
insulting real C because it doesn't have Your Favourite Toy Extension.
There's quite a large gap, there.

You might very well think that. I couldn't possibly comment.

[Keith Thompson]

Cesar Rabak <cs*****@yahoo.com.brwrites:

Keith Thompson escreveu:
[snipped]

In this case, one poster insists on discussing a specific extension
(operator overloading) implemented in a single compiler. I haven't
seen him or anyone else advocating that it be implemented in other
compilers, except possibly as a future standard feature.

Interesting. My reading differs from yours. Each time the
_possibility_ of adding this to the C (Standard) language is mentioned
he is flamed before can follow...

If he wants to advocating adding some feature to a future version of
the C standard, comp.std.c is the place to do so.

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

[Joe Wright]

Mark McIntyre wrote:

On Tue, 23 Jan 2007 14:26:51 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Jacob talks fancier stuff, "future and present of C language".

Right, and this is topical for comp.std.c, provided the proposer
doesn't start off by annoying and alienating the regulars there by
persistent rudeness or paranoia.

Just because you're paranoid, doesn't mean they're not after you. :-)

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Richard Heathfield]

Malcolm McLean said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message

>>
There is no such thing as overflow for unsigned integer types.

If you want to be pedantic about it,

Oh, I do, I do.

C offers a system modulus INT_MAX + 1.

Um, no it doesn't.

Personally I would happily trade the free modulus op for an infinite int,
or

a 64 bit int

which is almost as good. Integers usually count something, and you get a
lot of things in 64 bits.

I'd settle for 256-bit native integers. It would make encryption and
decryption a lot quicker.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>Cesar Rabak <cs*****@yahoo.com.brwrites:

>Keith Thompson escreveu:
[snipped]

In this case, one poster insists on discussing a specific extension
(operator overloading) implemented in a single compiler. I haven't
seen him or anyone else advocating that it be implemented in other
compilers, except possibly as a future standard feature.

Interesting. My reading differs from yours. Each time the
_possibility_ of adding this to the C (Standard) language is mentioned
he is flamed before can follow...

If he wants to advocating adding some feature to a future version of
the C standard, comp.std.c is the place to do so.

Or here in clc, the user community. There are enough of us on here who
are also on C.s.c and WG14 to give a view before they take it to c.s.c
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Mark McIntyre]

On Thu, 25 Jan 2007 09:09:17 +0000, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:

>In article <ln************@nuthaus.mib.org>, Keith Thompson

>>If he wants to advocating adding some feature to a future version of
the C standard, comp.std.c is the place to do so.

Or here in clc, the user community.

Perhaps, if its done in that fashion. However if someone does propose
an extension here then surely the purpose is to canvass opinion. Just
because that opinion is highly negative doesn't give the proposer the
right to abuse contributors or complain that they all hate him.

>There are enough of us on here who
are also on C.s.c and WG14 to give a view before they take it to c.s.c

Its a valuable sounding-board but proposers should also have the wit
not to flog dead horses and to consider the likelihood of their
proposal being well recieved. For example they should consider hard
before proposing such radical changes as would make C into a clone of
some other language, or would cause really serious performance
degradation, or would be nonportable over different hardware
platforms.

Consider posting to a ferrari newsgroup. If you posted a proposal that
ferrari should sell out to lada and start making three-wheelers, would
you expect to get kindly treated?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Kenny McCormack]

In article <kb********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
....

>>Or here in clc, the user community.

Perhaps, if its done in that fashion. However if someone does propose
an extension here then surely the purpose is to canvass opinion. Just
because that opinion is highly negative doesn't give the proposer the
right to abuse contributors or complain that they all hate him.

Pot. Kettle. Black.

In. Spades!

[jacob navia]

Mark McIntyre a écrit :

On Tue, 23 Jan 2007 14:26:51 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>>Jacob talks fancier stuff, "future and present of C language".

Right, and this is topical for comp.std.c, provided the proposer
doesn't start off by annoying and alienating the regulars there by
persistent rudeness or paranoia.

So, YOU treate me of "rude"...

In this same thread YOU wrote:

--------------------------------------------------------quote
On Sat, 20 Jan 2007 18:25:21 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>
I don't see your point. You mean C is just for writing games?

Idiot.

-- Mark McIntyre "Debugging is twice as hard as writing the code in the
first place. Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it." --Brian Kernighan

----------------------------------------------------end quote

Yes, that's you. But if YOU treat me of idiot *I* am rude of course!

[Chris Hills]

In article <kb********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.netwrites

>On Thu, 25 Jan 2007 09:09:17 +0000, in comp.lang.c , Chris Hills
<ch***@phaedsys.orgwrote:

>>In article <ln************@nuthaus.mib.org>, Keith Thompson

>>>If he wants to advocating adding some feature to a future version of
the C standard, comp.std.c is the place to do so.

Or here in clc, the user community.

Perhaps, if its done in that fashion. However if someone does propose
an extension here then surely the purpose is to canvass opinion. Just
because that opinion is highly negative doesn't give the proposer the
right to abuse contributors or complain that they all hate him.

Quite true.

>>There are enough of us on here who
are also on C.s.c and WG14 to give a view before they take it to c.s.c

Its a valuable sounding-board but proposers should also have the wit
not to flog dead horses

Some never learn and think if they come back in 3 months time we will
have gone away.

and to consider the likelihood of their
proposal being well recieved. For example they should consider hard
before proposing such radical changes as would make C into a clone of
some other language, or would cause really serious performance
degradation, or would be nonportable over different hardware
platforms.

Most people only see the language in light of their own programing
environment. C has to work on a VAX os running on an Alpha MCU and an 8
bit 8051with no OS and UNIX on PPC as well as Lunix and Win*** on
intel.

>Consider posting to a ferrari newsgroup. If you posted a proposal that
ferrari should sell out to lada and start making three-wheelers, would
you expect to get kindly treated?

Very kindly treated (they would assume you were an imbecile and on a
computer as therapy :-)

BTW would these be red, V12 turbo charged three wheelers with 2 seats
and no boot?

However I know what you mean I don't understand people who post to CLC
and say lets add all these C++ features to make C more like C++... WHY?

If you want those features use C++.
If there is no C++ for your platform ask WHY but not here....

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Mark McIntyre]

On Thu, 25 Jan 2007 13:38:52 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Mark McIntyre a écrit :

>>
Right, and this is topical for comp.std.c, provided the proposer
doesn't start off by annoying and alienating the regulars there by
persistent rudeness or paranoia.

So, YOU treate me of "rude"...

In this same thread YOU wrote:

<ja***@jacob.remcomp.frwrote:

>
I don't see your point. You mean C is just for writing games?

Idiot.

I got emailed this as well, so here's my response from the mail. By
the way, I also consider it extremely rude to copy someone by mail but
not mention you're doing that.
--- mailed response ---.

>So, YOU treate me of "rude"...

Yes (althought I think you mean 'accuse' rather than 'treate').

Lets be clear. Your remark which I commented on was either gratuitous
sarcasm, blatant stupidity or rudeness. I don't think you're stupid,
and I'm not sure your English is good enough for that level of
sarcasm.

Like I said, when you post your suggestions to CSC, I strongly
recommend you be polite, consider the responses calmly and without
taking them as personal insults, and avoid hurling invective at
people.

regards
Mark

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Kenny McCormack]

In article <gn********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netblathered on ad infinitum,
leading to:
....

>Like I said, when you post your suggestions to CSC, I strongly
recommend you be polite, consider the responses calmly and without
taking them as personal insults, and avoid hurling invective at
people.

Pot. Kettle. Black.

[Malcolm McLean]

"Keith Thompson" <ks***@mib.orgwrote in message

>

>which is almost as good. Integers usually count something, and you get a
lot
of things in 64 bits.

Types long long and unsigned long long are guaranteed to be at least
64 bits; there's no need to change the definition of type int. And
there are libraries that support arbitrary-precision integers (if they
were built into the language, the compiler would have to generate
calls to such a library anyway).

Programming languages are psychological as well as engineering entities.

You could have a mandatory deprecation of any integral type smaller than
long long. However it wouldn't catch on. Humans like to say that an integer
is an int. If ints were 64 bits then, save in a few rare legitimate special
cases, no one would use anything else, and the language would be simpler
and better.

[santosh]

Malcolm McLean wrote:

"Keith Thompson" <ks***@mib.orgwrote in message

which is almost as good. Integers usually count something, and you get a
lot
of things in 64 bits.

Types long long and unsigned long long are guaranteed to be at least
64 bits; there's no need to change the definition of type int. And
there are libraries that support arbitrary-precision integers (if they
were built into the language, the compiler would have to generate
calls to such a library anyway).

Programming languages are psychological as well as engineering entities.

You could have a mandatory deprecation of any integral type smaller than
long long. However it wouldn't catch on. Humans like to say that an integer
is an int. If ints were 64 bits then, save in a few rare legitimate special
cases, no one would use anything else, and the language would be simpler
and better.

Are you saying that you recommend using 64 bits for the char type too?

[Nick Keighley]

On Jan 24, 5:44 pm, atv <[e-mail]:

On 2007-01-19 12:28:03 +0100, Richard Heathfield <[e-mail]:

What it would do is allow beginners to write

#include <stdio.h>

int main(void)
{
int degrees_c;
scanf("%d", &degrees_c);
printf("...is %d in Fahrenheit.\n", (degrees_c * 9) / 5 + 32);
}

without writing something that is as undefined as, say, using gets.
We all know that this program is safer than one that uses gets, but
the standard does not say so and, to use your version of UB, nuclear
war may result from running it.

I hope that beginners would not write code like that, but I know that
they do. Yes, the program is safer than one containing a call to gets.
Nevertheless, it fails to check whether the degrees_c object has been
correctly populated, and it fails to check for overflow possibilities
before performing the multiplication.

Ok, i'm just wondering, how many people actually check for something
like 'the proper populating
of degrees_c, and conversion overflow (i didn't even think of that).
Seriously, i really would like
to know, because i've never seen any book or manual advocating this.

perhaps more should... Good software engineering texts probable do
<pause while scans bookshelf>
Sommerville "Software Engineering"
section 15.1 Fault avoidance
"All software engineers should aim to produce fault-free software."

Again, is this something i should be concerned about or is this only
applicable for safe based software (read NASA).

eek. All software that purports to solve real world problems should
strive to be correct. Or at least fail gracefully.

Do you really want your anti-lock brakes to fail, your phone to crash,
your print job to be scrambled and level 23 of Prince of Persia
to be lost?

It would probably add
some lines to my code. Aren't these issues which
the compiler should take care off and error out if these criteria
aren't satisfied ?

some are only detectable at run-time. If a signal is generated on
overflow
you still have to decide what to do about it.

I hope i misunderstood the above. In that case, just ignore me :-)

if you are writing toy programs then fine. If you are sure your
program
will crash rather than give wrong results then maybe ok.

But a comms system that loses packets or (much worse!) bits of
packets is just not acceptable.
--
Nick Keighley

"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup

[Malcolm McLean]

"santosh" <sa*********@gmail.comwrote in message

>You could have a mandatory deprecation of any integral type smaller than
long long. However it wouldn't catch on. Humans like to say that an
integer
is an int. If ints were 64 bits then, save in a few rare legitimate
special
cases, no one would use anything else, and the language would be simpler
and better.

Are you saying that you recommend using 64 bits for the char type too?

I've covered this in a previous post.

00011100
01000001
01010101
01000001
01011101
00100001
00011110
00000000