On the development of C

[Guest]

Still, I think that c can be a very good language precisely because of
its simplicity. It is the only high level language where there isn't any
"object oriented" framework that has been implemented in most current
languages, from java to cobol.

I don't believe C is the only high level language that doesn't have an
OO
framework. scheme, pascal, prolog most of the functional languages
etc.

 

[jfbode1029]

Yes, the regulars are ALWAYS complaining the eliminating gets() would
affect "millions of lines of code".  Here you join Gwyn and
many others (CBFalconer for instance).

But you get the facts wrong:

(1) gets() is not used a lot.

Has anyone done a comprehensive audit of the existing C code base to
determine how true that statement is? I don't use it, I doubt anyone
that participates in this newsgroup uses it, but we represent a tiny
fraction of everyone who's written a line of C over the last 35
years.

I have no doubt that there are systems out there still using gets()
because they're old or because they were written by programmers not
well versed in C or because the original programmers just didn't give
a crap. Is it *millions* of lines of code? Maybe, maybe not. But
I'm willing to bet there are more than a few legacy systems that would
be adversely affected. If you want to be the one to tell those people
it's for their own good, be my guest, but I'd rather not break
existing systems without *damn* good cause. This isn't exactly on the
same level as the Y2K bug, folks.

Throwing up a warning every time the compiler encounters a call to gets
() has been a good compromise, IMO.

(2) If it gets (no pun intended) used, it would be anyway better to
    rewrite that code...

That statement isn't in dispute, but other factors come into play,
such as budget, staffing, and schedule. First you have to find the
affected code, then you have to update and test it. Not all
organizations have the resources or motivation to do that.

 

[jacob navia]

That statement isn't in dispute, but other factors come into play,
such as budget, staffing, and schedule. First you have to find the
affected code, then you have to update and test it. Not all
organizations have the resources or motivation to do that.

Nobody is forcing anyone to stop using gets. It will be provided surely
in a compatibility library by the compiler vendors. The question here is
why should it stay in the standard!

 

[jfbode1029]

GREAT!

gets() is the best thing since sliced bread was discovered!

That's not what he said.

Obviously any critic to the language is out of the question.
Everything is correct, C has no problems at all. No new
developments are required.

That's not what he said.

Ignore all issues that I raise in my post, just a reply that doesn't say
anything and proposes the continuation of C90!

He's addressing your tendency towards hyperbole. C wasn't "destroyed"
by C++; C++ offered a set of tools that a large number of applications
programmers found preferable to C's comparatively limited toolset.
There was a tradeoff in performance and complexity, but enough
programmers felt the tradeoff was worth it. There a number of systems
I've coded in C++ that would have been harder to do in C.

No single language can be all things to all programmers. On the one
hand you want to keep C "simple", but some of the features you propose
like standardized containers would take away some of that
simplicity.

This guy is the best example of the regulars here. People like him
( or Gwyn) will take care of continuing the destruction of the language
by ignoring all criticism and proposing nothing else than the
continuation of the bugs of the past.

You're one to point fingers.

 

[jacob navia]

That's not what he said.


That's not what he said.

That's what his attitude implies.

The attitude of rejecting anything that goes beyond c89 or even ( as he
says sometimes in this group) beyond Turboc...

He's addressing your tendency towards hyperbole. C wasn't "destroyed"
by C++; C++ offered a set of tools that a large number of applications
programmers found preferable to C's comparatively limited toolset.

Then, as you said, the development of C ceased as a language. All new
developments went to C++ and C was discarded.

There was a tradeoff in performance and complexity, but enough
programmers felt the tradeoff was worth it. There a number of systems
I've coded in C++ that would have been harder to do in C.

Yes, nobody says that C++ should disappear. What we are talking about is
about C development.

No single language can be all things to all programmers. On the one
hand you want to keep C "simple", but some of the features you propose
like standardized containers would take away some of that
simplicity.

As you may know, writing a list is possible even in C. What I am
proposing is that a common interface is designed so that at each
application I do not have to recode the same code, and that applications
can be merged without having 100 list packages.

Suppose I use for lists interface1. I need to use in my application some
other library that also uses lists. Then I have already 2 lists packages.

I try to address this situation.

If we had a STANDARD interface for lists, we could always use the same
and be done with it.

 

[jameskuyper]

That's what his attitude implies.

No, it does not. He himself has criticized the language, and freely
admitted to particular problems (including some of the same ones that
bother you). All that you're angry about is that the problems he
recognizes differ from the ones you recognize.

What he was saying is that everything about C that used to work before
C++ was developed continued to work after C++ was developed. In other
words, he was criticizing your hyperbolic claim that C was "destroyed"
by the development of C++. To define a slowdown in the development of
C as evidence of it's "destruction" is ridiculous; a slowdown in
development is a routine, natural feature of maturity. The hectic pace
of development of pre-standard C cannot, and should not, reasonably be
expected to continue once the language had matured enough to be
standardized.

The attitude of rejecting anything that goes beyond c89 or even ( as he

He doesn't reject everything that goes beyond C89, though he certainly
has expressed disapproval of some of the new features. He just can't
afford to use it so long as he is bound to deliver a product that must
be usable by customers using C89 compilers. People who care about such
things don't use your compiler, which insulates you from awareness of
the existence of a market for such code.

....

Then, as you said, the development of C ceased as a language. ...

Those are your words, not his. He didn't say anything about
development of C or C++.

... All new
developments went to C++ and C was discarded.

So, all of the feature that were added to C since the development of C+
+ are just figments of our imagination? All of the changes from K&R C
that were made in C89, all of the changes made in the TCs that were
applied to C89, all of the changes that were made in C99, all of the
changes that were made in the 3 TCs to C99 - they were non-existent?
We should believe this, because you said so, and mistrust all of the
other evidence that suggests that C continued changing long after C++
was developed?

 

[jacob navia]

So, all of the feature that were added to C since the development of C+
+ are just figments of our imagination? All of the changes from K&R C
that were made in C89, all of the changes made in the TCs that were
applied to C89, all of the changes that were made in C99, all of the
changes that were made in the 3 TCs to C99 - they were non-existent?
We should believe this, because you said so, and mistrust all of the
other evidence that suggests that C continued changing long after C++
was developed?

Excuse me but very few people in the world had heard about C++ in
1989...

If you speak about the C89 standard, yes, that was a very positive
standard. It developed things like prototypes, that weren't at all
in the language before, and moved C a huge step forward.

The same can't be said from C99, and I do not see any real progress
in the issues I raised:

o The obsolete library
o The impossibility of writing new numeric types and as a consequence
the multiplication of "basic" types with the complexity of three
types of complex numbers.
o Genericity in tgmath.h but not in the language.

The fact that no work has been done in essential parts of the library
like malloc, for instance, where a function to know the size of an
allocated object would be a big step forward to ensure the absence
of buffer overflows.

Up to now your arguments do not go to the heart of the ISSUES
here. The library of C seems perfect to you?

The problem of the proliferation of numeric types is OK?

The problem of zero terminated string as the ONLY type
of string accepted is OK?

 

[user923005]

Has anyone done a comprehensive audit of the existing C code base to
determine how true that statement is?  I don't use it, I doubt anyone
that participates in this newsgroup uses it, but we represent a tiny
fraction of everyone who's written a line of C over the last 35
years.

I have no doubt that there are systems out there still using gets()
because they're old or because they were written by programmers not
well versed in C or because the original programmers just didn't give
a crap.  Is it *millions* of lines of code?  Maybe, maybe not.  But
I'm willing to bet there are more than a few legacy systems that would
be adversely affected.  If you want to be the one to tell those people
it's for their own good, be my guest, but I'd rather not break
existing systems without *damn* good cause.  This isn't exactly on the
same level as the Y2K bug, folks.

Throwing up a warning every time the compiler encounters a call to gets
() has been a good compromise, IMO.


That statement isn't in dispute, but other factors come into play,
such as budget, staffing, and schedule.  First you have to find the
affected code, then you have to update and test it.  Not all
organizations have the resources or motivation to do that.

I would argue that in view of the seriousness of the defect (it is a
well known exploit) any use of gets() in commercial code *must* be
fixed or the code vendor is negligent.

 

[Rui Maciel]

With the development of the c++ language, c was destroyed. Destroyed in
the sense that all language development ceased.

from http://dictionary.reference.com/browse/destroyed

de·stroy (dĭ-stroi') Pronunciation Key
v. de·stroyed, de·stroy·ing, de·stroys

v. tr.
1. To ruin completely; spoil: The ancient manuscripts were destroyed by fire.
2. To tear down or break up; demolish. See Synonyms at ruin.
3. To do away with; put an end to: "In crowded populations, poverty destroys the possibility of cleanliness" (George Bernard
Shaw).
4. To kill: destroy a rabid dog.
5. To subdue or defeat completely; crush: The rebel forces were destroyed in battle.
6. To render useless or ineffective: destroyed the testimony of the prosecution's chief witness.


I don't think that the C programming language has ever been close to be destroyed.


Rui Maciel

 

[lawrence.jones]

If you had claimed that development of C slowed down after C++ was
developed, you might have been able to argue that claim, though I have
no idea how to objectively measure such things.

Even that would be hard to justify since there wasn't much development
of C happening before that, either. Development of the language itself
was pretty much "done" in 1979, with the standard library following not
far behind. C has *never* undergone the kind of rapid (dare I say,
willy-nilly) development that C++ has, simply because that isn't
Ritchie's style. Some people consider stability to be a virtue, not a
shortcoming.

 

[lawrence.jones]

And I still do not understand what is so difficult with just erasing
that from the current documents! It is a matter of 5 minutes.

I'll just note that the COBOL standards committee was sued for removing
things from their standard. Changing the standard is easy (and cheap);
changing the real world to match is hard (and expensive).

 

[lawrence.jones]

user923005 said:

I don't think anyone with any sense disputes this, do they?

Yes, I think a few do. They don't, so far as I can tell, dispute that
it should be used only rarely if at all, but they do dispute that it
should be removed.

 

[jameskuyper]

Excuse me but very few people in the world had heard about C++ in
1989...

Speak for yourself. The new language was first called "C++" in 1983,
but development started as far back as 1979. The first commercial
release of C++ was in 1985, and "The C++ Programming Language" came
out at about that same time, serving as the unofficial standard for
the new language. As you can verify by reading that book, it was
already a very well developed language by that time. I first heard of
it no more than a year or two later, and I don't pay particularly
close attention to the IT industry news. At that time I still
considered myself primarily a scientist, who just used computers as a
tool in his work; I've since conceded that I'm a programmer who
specializes in scientific applications, but I still keep much closer
watch on developments in science than in IT.

....

The same can't be said from C99, and I do not see any real progress
in the issues I raised:

No progress on the issues you raised is something quite different from
no progress at all; thinking that they are the same is a rather self-
centered point of view.

Up to now your arguments do not go to the heart of the ISSUES

They're your issues, for the most part not of great interest to me.
You've raised them many times before, and I feel no need to repeat the
comments I've made about them in the past.

The falsehoods you've written in an attempt to promote your solutions
bother me much more than any of the problems you're complaining about.

 

[lawrence.jones]

As you may know, writing a list is possible even in C. What I am
proposing is that a common interface is designed so that at each
application I do not have to recode the same code, and that applications
can be merged without having 100 list packages.

I've never seen a "list" interface for C that wasn't more work and
trouble to use than just doing it myself.

 

[lawrence.jones]

Has anyone done a comprehensive audit of the existing C code base to
determine how true that statement is?

No, of course not. No one has access to "the existing C code base", or
even a substantial fraction of it. Everyone just assumes (without
justification) that the portion they do have access to is a
representative sample.

 

[Keith Thompson]

Liar yourself.


POI: MSVC supports 99% of C99, because C99 is largely the same as C89.


Then perhaps your familiarity with MSVC is on a par with your
familiarity with being rational and truthful in your posts?

I suggest that this is at least partly an honest miscommunication.
Yes, most of C99 consists of features that were present in C89/C90,
so a conforming C90 compiler does support most of C99 (I wouldn't
say it's 99%, but I'm not going to argue over the exact numbers).

On the other hand, when we say that a compiler supports C99, or
supports X% of C99, we usually mean that it supports (or supports X%
of) the features of C99 that aren't in C90.

jacob's use of the word "lie" is, as usual, inexcusably rude, but
apart from that he has a valid point.

My understanding is that MSVC has good support for C90, and very
little support for any C99 features that aren't in C90 (apparently //
comments and long long are exceptions to that). I haven't used MSVC,
so my understanding could well be incorrect.

You've done a survey have you? As compared to say, the ISO committees
which contains representatives of all the major compiler and most of
the major user groups.


I totally agree. However few companies are likely to want to spend
money rewriting code that works just to please a few language
fanatics. There's no money in it.

Companies can continue to use their existing compilers; the release of
the C99 standard certainly hasn't prevented anyone from using C90
compilers. And given that gets() has been in the language since time
immemorial, even conforming C201X compilers are likely to provide a
mode in which it's supported. Failing that, it's easy enough to
implement it yourself. Changing compilers will require changes to the
build process, and possibly to the code, anyway; working around any
lack of support for gets() shouldn't be especially burdensome. (And
hopefully companies will use this as an opportunity to stop using
gets() anyway.)

In my opinion, there has been ample warning that gets() should not be
used and might be removed from the language. I fully support removing
it from the language for the C201X standard. (But I'm not at all
concerned that this hasn't happened in the two *extremely* preliminary
201X drafts that have been released so far; there's no real reason to
do this before doing other work.)

 

[lawrence.jones]

I would argue that in view of the seriousness of the defect (it is a
well known exploit) any use of gets() in commercial code *must* be
fixed or the code vendor is negligent.

Not necessarily, the code may not run with any kind of elevated
privileges or only be used internally, in which case there's little to
no benefit to fixing the vulnerability.

 

[lawrence.jones]

Excuse me but very few people in the world had heard about C++ in
1989...

And yet the C committee, those stodgy backwards folks who don't know
what's going on in the rest of the world and refuse to ever change
anything, managed to adopt both function prototypes and the void type
from a language that very few people in the world had heard about.
Strange.

 

[jacob navia]

I suggest that this is at least partly an honest miscommunication.
Yes, most of C99 consists of features that were present in C89/C90,
so a conforming C90 compiler does support most of C99 (I wouldn't
say it's 99%, but I'm not going to argue over the exact numbers).

On the other hand, when we say that a compiler supports C99, or
supports X% of C99, we usually mean that it supports (or supports X%
of) the features of C99 that aren't in C90.

jacob's use of the word "lie" is, as usual, inexcusably rude, but
apart from that he has a valid point.

Well, but then you do not ask WHY Mr McIntyre is doing this?

Saying that MSVC supports 98% of C99 is an "honest
miscommunication" ???

Or is it a deliberate provocation ?

With your "reasonable" tone you always try to somehow
justify them. "Honest miscommunication" yes...

 

[Keith Thompson]

Keith Thompson wrote: [...]

jacob's use of the word "lie" is, as usual, inexcusably rude, but
apart from that he has a valid point.

Well, but then you do not ask WHY Mr McIntyre is doing this?

No. I'm more interested in why you persist in throwing around the
word "lie" or "liar" after you've been told multiple times how
offensive it is. You accuse people of deliberately making false
statements with the intent of deceiving others. You have no evidence
to support this, and you don't bother to ask for clarification before
making the accusation.

[snip]