On the development of C

[jacob navia]

Why C?

With the development of the c++ language, c was destroyed. Destroyed in
the sense that all language development ceased, and "naturally" all
developpers changed horses to the "new and improved" c++, leaving c as a
bad souvenir or at best a curiosity to be used in embedded systems or
similar environments where c++ doesn't cut it.

Many c++ books (specially some older ones) start with a chapter telling
people how bad C is, and why c++ solves all the problems of c. Of course
this is not very difficult to do since c remained as it was in 1989,
without any change.

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.

What are the main issues with C?

(1) The obsolete c library.
===========================
The c library is part of the language and it was one of the first
standardized, portable implementation of a language across a number of
computers.

In the 21st century however, it shows its age.

Its main problems are:

1.1: No support for standard containers like lists or hash tables
-----------------------------------------------------------------
A lack of a standard way to implement containers like lists,
flexible arrays, hash tables, and many others is one of the worst
features of the languages. This state of affairs means that each c
programmer must implement again and again the same routines, and start
each time with the debugging of the new code. It means also that it is
not possible to share code since each routine will use a slightly
different interface.

When it was proposed in the discussion group comp.std.c that the
standards committee standardizes a common interface, the "speaker" of
the committee, Mr Gwyn answered:
(Msg ID:<[email protected]> thread "C needs a BOOST",
10/4/2007)

--------------------------------<quote>
The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.
------------------------------<end quote>

The argument of the committee speaker is then:
(A) Old programs have already lists and container code. They
do not need any new specification.
(B) New programs should not be written in c but in "higher-level"
languages.

This is the attitude of many people in the standards committee and in
the c/c++ programming community in general. C is dead and the best thing
to do is to maintain it in that situation.

I disagree profoundly with this attitude.

1.2: A completely obsolete representation of strings.
----------------------------------------------------
The "C strings" are represented by a sequences of characters in memory
followed by a zero byte. Since they have to be maintained manually (it
is the responsability of the programmer to maintain that terminating
zero) it offers ample opportunities for errors. This errors are
directly the consequence of the bad data structure, but somehow this
representation has been standardized into the language itself so that
there is no other way to work with strings and use the standard
library.

1.3 Wrongly specified and buggy library functions.
-------------------------------------------------
One of the evergreens of people critizing the c language is the
function "gets". This function is supposed to read characters from some
file into a buffer, but it doesn't provide any means to test if the end
of the buffer is reached, so it is impossible by design to use it in a
manner that ensures the absence of a buffer overflow.

I have been discussing this (and other) function since several years in
the discussion group comp.std.c. Nobody from the many people present in
those discussions has ever tried to justify gets(), except the
committee representative Mr Gwyn, that defended it against all odds.

The committee has accepted that this function is declared obsolete but
apparently it has still not gotten around to eliminate it from the
language: it still appears in the drafts for the new standard as of
March 2009.

Other functions are less obviously wrong but nevertheless far from what
would be correct specifications for a language to be used in the 21st
century. Most of the functions in the C library fail to do the most
elementary error analysis, reflecting the time when error analysis and
bullet proof software was not needed since software was used in
controlled and secure environments. The ocassional crash because of bad
inputs was a necessary evil.

The problem is that (again) the standards committee doesn't see this as
a problem at all. For instance, we have the asctime() function
specified in the standard as a code listing. Problem is, if you happen
to give this function a date that is beyond the year 8099 it will
exhibit a buffer overflow. So we have the incredible situation where a
function exhibiting a buffer overflow is printed in the standards text,
and the committee refuses to acknowledge this fact since at least 10
years.

2: Language issues
==================

(2.1) It is impossible to create new numeric types
------------------------------------------------
C features already an incredible number of numeric types. We have:
o _Bool (1 bit type)
o char (small int) signed+unsigned
o short signed+unsigned
o int signed+unsigned
o long signed+unsigned
o long long signed+unsigned
o float
o double
o long double
o _Complex float
o _Complex double
o _Complex long double

All those aren't needed at the same type in all applications, specially
the _Complex types. Besides those, there are technical reports
presented already to the committee that propose decimal based numbers,
fixed point numbers, and possibly others.

It is clear that if we are going to support all possible types, the
language will grow beyond what is reasonable to expect. The solution
for this "problem" is simple, and will be discussed in the "proposals"
section.

(2.2) It is impossible to create another type of strings
------------------------------------------------------
Many libraries exist that implement counted strings, but they all
require the user to forget the natural notation str[5] = 'a' and adopt
a cumbersome notation in the style of:

asgnstr(str,5,'a');

Luckily the solution to this problem is the same as in (2.1). See below.

3: The proposed solutions
=========================
3.1 The solutions to the language problems.

In the lcc-win compiler I have developed a solution to the language
problems, that simplifies the language and at the same time opens it up
to the user.

Operator overloading is an accepted technique in many languages, from
the venerable FORTRAN to C#. lcc-win proposes this solution to:

o Develop new kinds of numbers.
To prove the concept, (and debug it) lcc-win has used operator
overloading to implement 352 bits floats, boasting 105 decimal digits
of precision.
o Develop a counted string library using operator overloading to access
the strings with [ and ] instead of the more cumbersome function call
notation.

This single solution allows to solve both problems, and allows at the
same time to take complex numbers OUT of the language, making it
smaller. At the same time, the language could accomodate the proposed
decimal and fixed point numbers, using the same interface.

3.2 The solutions to the library problems.
------------------------------------------
Microsoft has proposed a set of more secure functions that should
replace the unsecure ones. The particular definitions of those library
functions aren't so much interesting in this context. What *IS*
relevant is that the error analysis is an integral part of the
specifications. All arguments allowed value ranges are described, and
the possible errors enumerated. The language should take this way of
specifying the functions inthe library as a guideline to be used in the
specifications of ALL functions in the library.

The new C standard should specify an interface for containers like lists
or hash tables. Again, I have developed basic examples in the lcc-win
compiler. I have published the code in the discussion group comp.lang.c.

Conclusion
==========

The proposed changes do not alter fundamentally the nature of C. They
are very small and maintain the essential simplicity of the language.

True, C is simple.

But, as Einstein said, things should be as simple as possible but not
simpler.

 

[user923005]

Why C?

With the development of the c++ language, c was destroyed. Destroyed in
the sense that all language development ceased, and "naturally" all
developpers changed horses to the "new and improved" c++, leaving c as a
bad souvenir or at best a curiosity to be used in embedded systems or
similar environments where c++ doesn't cut it.

Many c++ books (specially some older ones)  start with a chapter telling
people how bad C is, and why c++ solves all the problems of c. Of course
this is not very difficult to do since c remained as it was in 1989,
without any change.

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.

What are the main issues with C?

(1) The obsolete c library.
===========================
The c library is part of the language and it was one of the first
standardized, portable implementation of a language across a number of
computers.

In the 21st century however, it shows its age.

Its main problems are:

1.1: No support for standard containers like lists or hash tables
-----------------------------------------------------------------
A lack of a standard way to implement containers like lists,
flexible arrays, hash tables, and many others is one of the worst
features of the languages. This state of affairs means that each c
programmer must implement again and again the same routines, and start
each time with the debugging of the new code. It means also that it is
not possible to share code since each routine will use a slightly
different interface.

When it was proposed in the discussion group comp.std.c that the
standards committee standardizes a common interface, the "speaker" of
the committee, Mr Gwyn answered:
(Msg ID:<[email protected]> thread "C needs a BOOST",
10/4/2007)

--------------------------------<quote>
The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc.  The maintenance programmer
(a)is  unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome.  Much
new development really ought to use higher-level languages in
the first place.
------------------------------<end quote>

The argument of the committee speaker is then:
   (A) Old programs have already lists and container code. They
       do not need any new specification.
   (B) New programs should not be written in c but in "higher-level"
       languages.

I don't think you can make truly generic C data structures and
algorithms in C the same as C++ because C lacks templates. The
closest you can come is with void pointers and that isn't very close.

This is the attitude of many people in the standards committee and in
the c/c++ programming community in general. C is dead and the best thing
to do is to maintain it in that situation.

I disagree profoundly with this attitude.

1.2: A completely obsolete representation of strings.
----------------------------------------------------
The "C strings" are represented by a sequences of characters in memory
followed by a zero byte. Since they have to be maintained manually (it
is the responsability of the programmer to maintain that terminating
zero) it offers ample opportunities for errors. This errors are
directly the consequence of the bad data structure, but somehow this
representation has been standardized into the language itself so that
there is no other way to work with strings and use the standard
library.

1.3 Wrongly specified and buggy library functions.
-------------------------------------------------
One of the evergreens of people critizing the c language is the
function "gets". This function is supposed to read characters from some
file into a buffer, but it doesn't provide any means to test if the end
of the buffer is reached, so it is impossible by design to use it in a
manner that ensures the absence of a buffer overflow.

I have been discussing this (and other) function since several years in
the discussion group comp.std.c. Nobody from the many people present in
those discussions has ever tried to justify gets(), except the
committee representative Mr Gwyn, that defended it against all odds.

The committee has accepted that this function is declared obsolete but
apparently it has still not gotten around to eliminate it from the
language: it still appears in the drafts for the new standard as of
March 2009.

Other functions are less obviously wrong but nevertheless far from what
would be correct specifications for a language to be used in the 21st
century. Most of the functions in the C library fail to do the most
elementary error analysis, reflecting the time when error analysis and
bullet proof software was not needed since software was used in
controlled and secure environments. The ocassional crash because of bad
inputs was a necessary evil.

The problem is that (again) the standards committee doesn't see this as
a problem at all. For instance, we have the asctime() function
specified in the standard as a code listing. Problem is, if you happen
to give this function a date that is beyond the year 8099 it will
exhibit a buffer overflow. So we have the incredible situation where a
function exhibiting a buffer overflow is printed in the standards text,
and the committee refuses to acknowledge this fact since at least 10
years.

There are a few bad library functions, and a few bad designs (e.g. %s
without a width specifier should not be allowed for reads).
I think it would be good to ban gets() and also remove %s without a
width for reading.

2: Language issues
==================

(2.1) It is impossible to create new numeric types
------------------------------------------------
C features already an incredible number of numeric types. We have:
o _Bool (1 bit type)
o char (small int) signed+unsigned
o short signed+unsigned
o int signed+unsigned
o long signed+unsigned
o long long signed+unsigned
o float
o double
o long double
o _Complex float
o _Complex double
o _Complex long double

You can create other types, but they don't have convenient
nomenclature.
IOW, MPFR creates extended precision types. You can manipulate them
with function calls but not with operators.
However, it will be hard to add operator support without references
and operator overloading. C has neither.

All those aren't needed at the same type in all applications, specially
the _Complex types. Besides those, there are technical reports
presented already to the committee that propose decimal based numbers,
fixed point numbers, and possibly others.

It is clear that if we are going to support all possible types, the
language will grow beyond what is reasonable to expect. The solution
for this "problem" is simple, and will be discussed in the "proposals"
section.

(2.2) It is impossible to create another type of strings
------------------------------------------------------
Many libraries exist that implement counted strings, but they all
require the user to forget the natural notation str[5] = 'a' and adopt
a cumbersome notation in the style of:

asgnstr(str,5,'a');

Luckily the solution to this problem is the same as in (2.1). See below.

The string in C is not a real data type either. It's just an array
that happens to have an embedded zero.
I think that alternative string formats could easily have just as much
weight as the current C string type.
The only reason that C strings are ubiquitous in C is that all the
library functions assume that type.
If equivalent library functions were created for a new and better
type, it would overcome that problem.

3: The proposed solutions
=========================
3.1 The solutions to the language problems.

In the lcc-win compiler I have developed a solution to the language
problems, that simplifies the language and at the same time opens it up
to the user.

Operator overloading is an accepted technique in many languages, from
the venerable FORTRAN to C#. lcc-win proposes this solution to:

o Develop new kinds of numbers.
   To prove the concept, (and debug it) lcc-win has used operator
   overloading to implement 352 bits floats, boasting 105 decimal digits
   of precision.

You can get that right now by downloading and building the Cephes
collection. You don't have the convenient:
z = x + y;
notation, but that is the penalty for using C instead of C++. I
happen to like the LCC extension you have provided, but it does not
seem to solve the problem generically. If you are proposing
references and operator overloading, I still think that we will also
need constructors to initialize, and therefore destructors also. We
are getting awfully close to C++ here, wouldn't you agree?

o Develop a counted string library using operator overloading to access
   the strings with [ and ] instead of the more cumbersome function call
   notation.

I don't find operators all that helpful on strings. Aside from string
addition, what other operators will be useful against strings? Almost
all C++ string operations are done with methods and not operators.

This single solution allows to solve  both problems, and allows at the
same time to take complex numbers OUT of the language, making it
smaller. At the same time, the language could accomodate the proposed
decimal and fixed point numbers, using the same interface.

3.2 The solutions to the library problems.
------------------------------------------
Microsoft has proposed a set of more secure functions that should
replace the unsecure ones. The particular definitions of those library
functions aren't so much interesting in this context. What *IS*
relevant is that the error analysis is an integral part of the
specifications. All arguments allowed value ranges are described, and
the possible errors enumerated. The language should take this way of
specifying the functions inthe library as a guideline to be used in the
specifications of ALL functions in the library.

The new C standard should specify an interface for containers like lists
or hash tables. Again, I have developed basic examples in the lcc-win
compiler. I have published the code in the discussion group comp.lang.c.

A standard function library would be very nice. I think it would be
very hard to design it properly. If this does get accomplished, it
would be a great achievement.

 

[jacob navia]

You can get that right now by downloading and building the Cephes
collection. You don't have the convenient:
z = x + y;
notation, but that is the penalty for using C instead of C++. I
happen to like the LCC extension you have provided, but it does not
seem to solve the problem generically. If you are proposing
references and operator overloading, I still think that we will also
need constructors to initialize, and therefore destructors also. We
are getting awfully close to C++ here, wouldn't you agree?

lcc-win doesn't implement neither constructors nor destructors.

They aren't needed at all.

All numbers are small enough to be passed by value, sparing any need for
destructors.

And for objects that are bigger than what can be reasonable passed by
value, lcc-win offers a garbage collector.

Other solutions are possible like using a typed memory heap, and other
more limited forms of a garbage collector.

 

[jacob navia]

"C overwhelmingly proved the most popular programming language
for thousands of new open-source projects in 2008 [...}"
-- http://www.theregister.co.uk/2009/01/21/open_source_projects_08/

Yet another Navia assertion bites the dust.

I said

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

I did not said that nobody uses C.

Your way of answering is as usual.

Take one sentence, deform it, (straw man), then laugh at it in a short
sentence.

No argumentation concerning the long message at all. No counter
proposal, not anything positive. Just laugh at the efforts of others
without ever contributing anything new to the discussion.

This is the same negative attitude of the other regulars...

 

[user923005]

lcc-win doesn't implement neither constructors nor destructors.

They aren't needed at all.

All numbers are small enough to be passed by value, sparing any need for
destructors.

And for objects that are bigger than what can be reasonable passed by
value, lcc-win offers a garbage collector.

Other solutions are possible like using a typed memory heap, and other
more limited forms of a garbage collector.

This approach may work with Cephes qfloat, but other advanced floating
types will require constructors and destructors. If you are
advocating the addition only of qfloat, then I think we do not need
anything special added to the language to get a single new type
included.

 

[jacob navia]

This approach may work with Cephes qfloat, but other advanced floating
types will require constructors and destructors. If you are
advocating the addition only of qfloat, then I think we do not need
anything special added to the language to get a single new type
included.

MPFR can be accomodated with the GC. The gc is an incredibly powerful
solution for really BIG numbers like lcc-win's bignums that can contain
an unlimited number of 32 bit integers.

You just create objects and leave the hard work of freeing them to the
GC!

 

[jameskuyper]

Why C?

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

False. C had not even been standardized when C++ was first developed.
The first standard went beyond standardization of existing practice,
and added a number of new features to the language. The same is true,
to a lesser extent, of the second version of the standard, as well as
of each of the TC's that were approved. And that's just the language
standard; development of new features that have not yet (and in many
cases, might never be) standardized has been quite common among C
implementors.

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. However, you've made
the manifestly false claim that development ceased, and that's
trivially to disprove.

... and "naturally" all
developpers changed horses to the "new and improved" c++,

Manifestly untrue, or comp.lang.c wouldn't be anywhere near as active
as it actually is.

....

When it was proposed in the discussion group comp.std.c that the
standards committee standardizes a common interface, the "speaker" of
the committee, Mr Gwyn answered:

Doug Gwyn is just a committee member. He is in no sense the official
"speaker" for the committee, he's just one of the most outspoken of
the few committee members occasionally monitoring comp.lang.c or
comp.std.c.

(Msg ID:<[email protected]> thread "C needs a BOOST",
10/4/2007)

--------------------------------<quote> ....
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.
------------------------------<end quote>

The argument of the committee speaker is then: ....
(B) New programs should not be written in c but in "higher-level"
languages.

That is a blatant misrepresentation. You continue to pretend that
"Much new development" means the same thing as "All new development",
despite the fact that I quite recently informed you of the fact that,
in English, there's a big difference between the two phrases.
"Much ..." doesn't even imply "A majority of ...", it can refer to a
percentage much smaller than 50%.

1.2: A completely obsolete representation of strings.
----------------------------------------------------
The "C strings" are represented by a sequences of characters in memory
followed by a zero byte. Since they have to be maintained manually (it
is the responsability of the programmer to maintain that terminating
zero) it offers ample opportunities for errors. This errors are
directly the consequence of the bad data structure, but somehow this
representation has been standardized into the language itself so that
there is no other way to work with strings and use the standard
library.

Null terminated strings have their problems and their advantages; but
so long as backwards compatibility is important (and it is very
important to the committee), support for them cannot be removed - it
would break huge quantities of existing code. The most that could
possibly happen would be the addition of support for other types of
strings.

1.3 Wrongly specified and buggy library functions.
-------------------------------------------------
One of the evergreens of people critizing the c language is the
function "gets". This function is supposed to read characters from some ....
The committee has accepted that this function is declared obsolete but
apparently it has still not gotten around to eliminate it from the
language: it still appears in the drafts for the new standard as of
March 2009.

As you've been informed many times already, the documents you're
referring to are working documents, not drafts. The first draft will
probably not be published until sometime around the end of this year.
The absence of changes that you're looking for from the working
documents doesn't mean anything yet. The committee has much more
urgent business to attend to than gets().

 

[jameskuyper]

Why C?

With the development of the c++ language, c was destroyed. Destroyed in
the sense that all language development ceased, and "naturally" all
developpers changed horses to the "new and improved" c++, leaving c as a
bad souvenir or at best a curiosity to be used in embedded systems or
similar environments where c++ doesn't cut it.

"C overwhelmingly proved the most popular programming language
for thousands of new open-source projects in 2008 [...}"
-- http://www.theregister.co.uk/2009/01/21/open_source_projects_08/

Yet another Navia assertion bites the dust.

I said

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

I did not said that nobody uses C.

No, but you came close, in ways that are incompatible with Eric's
counter-example:

... all
developpers changed horses to the "new and improved" c++, leaving c as a
bad souvenir or at best a curiosity to be used in embedded systems or
similar environments where c++ doesn't cut it.

That description is just not consistent with a C being "the most
popular programming language for ... new open-source projects", not
unless "embedded systems or similar environments where c++ doesn't cut
it" are so commonplace that they cannot possibly count as
"curiosities".

 

[CBFalconer]

.... snip ...

The c library is part of the language and it was one of the first
standardized, portable implementation of a language across a
number of computers.

In the 21st century however, it shows its age.

Its main problems are:

1.1: No support for standard containers like lists or hash tables
-----------------------------------------------------------------
A lack of a standard way to implement containers like lists,
flexible arrays, hash tables, and many others is one of the worst
features of the languages. This state of affairs means that each
c programmer must implement again and again the same routines,
and start each time with the debugging of the new code. It means
also that it is not possible to share code since each routine
will use a slightly different interface.

As far as hash tables are concerned, my hashlib is available,
compact, believed to be bug-free, and is written purely in standard
C, thus portable anywhere. It, together with testing and
demonstration code, is available (under GPL) at:

<http://cbfalconer.home.att.net/download/hashlib.zip>

 

[jacob navia]

False. C had not even been standardized when C++ was first developed.
The first standard went beyond standardization of existing practice,
and added a number of new features to the language. The same is true,
to a lesser extent, of the second version of the standard, as well as
of each of the TC's that were approved.

There are absolutely no new language features in C99. True, boolean and
complex types were added, but I am not impressed really. The new keyword
"restrict" was added. Other syntax sugar in structure initialization
and we are done. That's really no new development, even if they are more
than just cosmetic changes.

And that's just the language
standard; development of new features that have not yet (and in many
cases, might never be) standardized has been quite common among C
implementors.

gcc stopped any C development ages ago. The same for Microsoft MSVC.
Microsoft hasn't even bothered to implement C99. "New features"???
Yes, I mention the new development that Microsoft proposes in my
article. But no new language features at all in any of them.

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. However, you've made
the manifestly false claim that development ceased, and that's
trivially to disprove.

Well, it is trivial to agree to that. If you like s/ceased/slowed down/

Manifestly untrue, or comp.lang.c wouldn't be anywhere near as active
as it actually is.

This is a group where the main topics aren't at all any development of
the C language. Each time I have tried to start a conversation about
that a group of people here (that you know surely well) starts screaming
"off topic", etc.

Mostly this group is about
(1) Doing lazy students homework
(2) Insisting that void main() is an error and that p++ = p++ + p++ is
undefined, and similar questions.
(3) Polemics between the regulars and the other people.
(4) Scanf problems

...

Doug Gwyn is just a committee member. He is in no sense the official
"speaker" for the committee, he's just one of the most outspoken of
the few committee members occasionally monitoring comp.lang.c or
comp.std.c.


That is a blatant misrepresentation. You continue to pretend that
"Much new development" means the same thing as "All new development",
despite the fact that I quite recently informed you of the fact that,
in English, there's a big difference between the two phrases.

I think you are distorting english to please your needs.

"Much ..." doesn't even imply "A majority of ...", it can refer to a
percentage much smaller than 50%.

If you look at dictionary.com under "much"

–noun
2. a great quantity, measure, or degree: Much of his research was
unreliable.

OK?

Null terminated strings have their problems and their advantages; but
so long as backwards compatibility is important (and it is very
important to the committee), support for them cannot be removed - it
would break huge quantities of existing code. The most that could
possibly happen would be the addition of support for other types of
strings.

This is exactly what I propose. Zero terminated strings should be left
as they are but the language should be able to support other types of
strings!

At least we agree on this.

As you've been informed many times already, the documents you're
referring to are working documents, not drafts. The first draft will
probably not be published until sometime around the end of this year.
The absence of changes that you're looking for from the working
documents doesn't mean anything yet. The committee has much more
urgent business to attend to than gets().

Yeah sure. They could have done this for C99 isn't it? The big trouble
of C99 was that it basically left C89 as it was, with all problems
associated with the obsolete library.

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.

 

[jacob navia]

jacob navia said:


Simple, fast, portable, stable. C99 breaks three of these (although
hopefully two of them can eventually be fixed), but all four
advantages do still apply to C90.


How strange. It still works just fine over here.

GREAT!

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

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.

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

I disagree. Every new function is effectively an extension of the
language.

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.

 

[Daniel Pirch]

"C overwhelmingly proved the most popular programming language for
thousands of new open-source projects in 2008 [...}" --
http://www.theregister.co.uk/2009/01/21/open_source_projects_08/

Yet another Navia assertion bites the dust.

Only if you believe a report whose authors obviously aren't aware that C
and C++ are different languages.

 

[jameskuyper]

There are absolutely no new language features in C99. True, boolean and
complex types were added, but I am not impressed really.

You're free to be unimpressed by the new language features of C99, but
I have to object to your false claim that there are none. Section 5 of
the Forward lists 54 new features. I won't attempt to detemine how
many of those new features are language features rather than library
features, because the distinction is irrelevant to both your point,
and mine.

gcc stopped any C development ages ago. The same for Microsoft MSVC.
Microsoft hasn't even bothered to implement C99. "New features"???

You attributed the end of C development to the development of C++. gcc
didn't even exist yet when C++ was first developed. All gcc C
development has occurred since that time. Therefore, according to your
claim, it must never have happened. That will come as big news to the
large community of people who use gcc as their main C compiler.

....

This is a group where the main topics aren't at all any development of
the C language. Each time I have tried to start a conversation about
that a group of people here (that you know surely well) starts screaming
"off topic", etc.

Mostly this group is about
(1) Doing lazy students homework

Odd - they're doing C homework when all developers have already
changed over to C++. They must have truly cruel professors.

....

(4) Scanf problems

If everyone has already switched over to c++, why are they asking
about scanf()? They should be using operator>>().

I think you are distorting english to please your needs.

Nope, "much" does NOT mean "all". It doesn't even have to imply
"most". If you won't take my word for it as a native speaker of
English, I don't know what to say to you. Given the rest of Doug's
comments, it's quite clear that the thinks there's considerable amount
of new development that should, and does, continue to be done in C.

If you look at dictionary.com under "much"

�noun
2. a great quantity, measure, or degree: Much of his research was
unreliable.

OK?

20% can be a great quantity, if it is 20% of a sufficiently large
total. And such usage is entirely consistent with ordinary English
usage. Example: most of the water I drink is bottled, but much of it
is not.

....

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

Erasing it is not the problem. Larry can do that in seconds, I
presume, once the decision has been discussed and approved. Going
through the proper process of reaching that decision is what takes a
lot of time. As Larry Jones has pointed out, purely editorial changes
can be made just by pointing them out to him (removing a standard
library function is NOT an editorial change). However, for just about
anything more complicated, there's an absolute minimum amount of work
that needs to be done to meet ISO requirements, to make sure that no
changes are made without due consideration.

 

[luser-ex-troll]

o Develop a counted string library using operator overloading to access
   the strings with [ and ] instead of the more cumbersome function call
   notation.

I don't find operators all that helpful on strings.  Aside from string
addition, what other operators will be useful against strings?  Almost
all C++ string operations are done with methods and not operators.

It'd be nice to replace sprintf() with multiplying
a format string by a list.
Or dividing a string by a delimiter string to replace
strtok().
Or subtracting a character from a string to remove all
occurrences of that character (au lieu de strtok + loop{strcat}).

Yay operators!

lxt.

 

[jacob navia]

user923005 wrote:

o Develop a counted string library using operator overloading to access
the strings with [ and ] instead of the more cumbersome function call
notation.

I don't find operators all that helpful on strings. Aside from string
addition, what other operators will be useful against strings? Almost
all C++ string operations are done with methods and not operators.

The operator overloading is only needed to make code like
Str[2] = 'a';

work, instead of forcing the user to write

strasgn(Str,2,'a');

I have rewritten the standard library string functions using
counted strings. Strcat replaces strcat, Strlen replaces strlen,
etc.

The code allows porting the code using the zero terminated strings to
the new strings with minimal modifications. And one of the biggest
problems when porting code to the new string representation is
that code like Str[2] = 'a'; doesn't work any more.

Operator overloading allows that syntax with the new strings.

 

[jacob navia]

o Develop a counted string library using operator overloading to access
the strings with [ and ] instead of the more cumbersome function call
notation.

I don't find operators all that helpful on strings. Aside from string
addition, what other operators will be useful against strings? Almost
all C++ string operations are done with methods and not operators.

It'd be nice to replace sprintf() with multiplying
a format string by a list.
Or dividing a string by a delimiter string to replace
strtok().
Or subtracting a character from a string to remove all
occurrences of that character (au lieu de strtok + loop{strcat}).

Yay operators!

lxt.

Yay luser!

See my reply to user923005

 

[jacob navia]

I hesitate to point it out but this is a deeply disingenuous statement,
given that a decade has past since C99 was published, and many years ago
both organizations added some but not all features of C99 to their
suites. gcc is close to claiming C99 conformance. MSVC isn't likely to,
but does support much of C99.

This is a big lie. MSVC doesn't support even 1% of C99. All they
support is // comments and (since version 2008) long long.

As far as I know, nothing else is supported.

And how about erasing it from the millions of compilers out there,and
the billions of lines of code? Oh, I forgot - you really don't give a
sh*t about actual real world issues.

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.
(2) If it gets (no pun intended) used, it would be anyway better to
rewrite that code...

 

[user923005]

This is a big lie. MSVC doesn't support even 1% of C99. All they
support is // comments and (since version 2008) long long.

99.7325% of all statistics are made up.

Sun Studio contains a complete C99 compiler for free.

As far as I know, nothing else is supported.



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

I do not believe anyone has said that removing gets() would affect
millions of lines of code.
If it were true, then we are correcting millions of lines of defects.
I guess that there are not one million distinct lines of C code
calling gets() in the world.
But if there were, all one million lines of code need to be changed.

But you get the facts wrong:

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

Here I side with Jacob. There is no place for gets() in the C
language, now that it is abundantly clear that people with malevolent
intentions can exploit that defect.
Furthermore, if gets() is used a lot, then all the *more* reason to
remove it.

 

[Dik T. Winter]

> jameskuyper wrote: ....
>
> I think you are distorting english to please your needs.

Not at all.

>
> If you look at dictionary.com under "much"
>
> noun
> 2. a great quantity, measure, or degree: Much of his research was
> unreliable.

Where is it stated that it is a majority? Or where is it stated that it
is more than 50%?

If I state "beaucoup des inhabitants de Paris utilisent les bicyclettes
blanc" do I mean that it is the majority, or that it is more than 50%
that uses the white bicycles? Much can be much, even when it is a small
precentage.

 

[Dik T. Winter]

> The operator overloading is only needed to make code like
> Str[2] = 'a';

Operator overloading is not a panacea for everything. C knows operator
overloading, but only dependent on the arguments presented. When you also
do allow overloading on the result the effect can be horrendous. Doing
overload resolving is a problem in complex expressions can be difficult.
I know only one language that actually does have it completely: Ada. There
have been papers written on overload resolving.