Thomas Richter a écrit :
Given the amount of existing code that builds on the existing C library,
replacing it is actually plain nonsense.
Nobody is proposing that. This is an old trick in this discussions. Any
improvement to C is impossible because the old code. That is plainly not
true. The old code and the associated functions can be kept, but C
should be able to use BUFFERS of KNOWN length, avoiding the most common
cause of buffer overflows. Let's be explicit:
typedef struct {size_t length; char data[];} Buffer;
memset can be done as "Memset", for instance like this
bool Memset(Buffer *dest, int char_val);
where:
The result is zero if buffer is NULL, 1 if buffer is not null.
This is an easy example. Strcpy is just as trivial, but with a character
buffer.
Giving a similar but different name easies the porting and is compatible
with old code.
Why argument with flawed arguments? I DID tell jun my message that I
renamed the string functions Strcpy for instance. Why arguing that I
`want to "replace" strcpy"? Of course I want to replace the
functionality, making it less error prone, but not the function.
I don't think they're wrong. They require care, care some people forgot..
This has been discussed and discussed, and the essential point is that
if somebody makes a mistaken once, it is his/her fault. Ifvthousands of
programmers make always the same errors it is the tool's fault. In this
group, r Heathfield, an experienced C programmer had to acknowledge
that his published code had a BUG in his code handling string data.
And Mr Heathfield has been somebody that ALWAYS sys exactly the same as
you now. "You have to be careful" etc. But he himself was proved wrong.
I am sure you can be proved wrong too.
As for example checking for the proper buffer size. A "strcpy" can be
absolutely correct if you have control on the size of the input string,
and it can be completely fatal if not.
Exactly. A better version would use COUNTED buffers!
If you want to avoid the hassle,
go for C++, or use the limiting functions.
Here we have it again. Any development of C is always answered with
"Go to C++" even by committee members. C should remain full of warts
so that C++ can be seen as the only alternative. There should be NO
simpler language than C++, all development of C as a language should
STOP.
You are confirming what I say about committee members.
{snip}
Why should there? C is a very small language, and I really don't see the
need for such simple data structures in the standard.
Then, each C programmer needs to port a library that does lists,
flexible arrays, or find and debug one and port it, etc.
If you need
library support for that, and a richer structure that helps you with
such containers, use C++ and the STL.
OF COURSE that is the solution. Yu are (again) confirming what I said:
All development in C should stop and we should swallow C++ if we want to
do the simplest tasks!
If we want to use (portably) a list, we are forced to use C++ and
their STL...
This is what it has been designed
for.
C is still being used, and many important projects are based on it. My
thesis is that a simple language is necessary and useful. Adding
a general and extensible container interface for C doesn't change at all
the language but gives C programmer the advantages of not having to
program the same data structures over and over.
The proliferation of libraries that do the same thing WITHOUT a standard
in C means that each big project in C has several versions of the same
data structure because library XYZ uses lists with the "Next" field
in the fiorst position and library"XXX" uses a list with Next in the
second position. Besides all APIs are different, etc.
This is SO OBVIOUS that doesn't even need to be discussed. But C should
be kept in its present state so taht the only alternative is to swallow
C++
Well, you confirm everything that I said.
