Text-Based Windows Library

[Charlton Wilbur]

EJ> Therefore, given that C developers lose nothing (they can keep
EJ> using regular C strings), and only incur the overhead of
EJ> "safe" strings if they choose it, I really don't see what the
EJ> debate is all about.

Violent agreement; on my usual programming platform, for instance, I
use CFStrings on a regular basis for just that reason. I accept the
drawbacks (more overhead, reduced portability) in exchange for a
number of other benefits (more automatic memory management, safety
from buffer overruns, easier internationalization because of Unicode
support). C strings are still there for me to use, but the tradeoffs
make them not worth it.

Programmers who cannot competently manage C strings themselves and who
refuse to use any of the available safe string libraries are, in a
word, stupid. Managers who hire such programmers -- or who, having
hired programmers who cannot competently manage C strings, prohibit
them from using safe string libraries -- are, in three words, *really*
@#$%ing stupid.

Charlton

 

[Richard Bos]

I think that this is a dangerous oversimplification, because the
language allows:
gets(str);
and
scanf() with %s
and memcpy which does not know how long the objects are
and strcpy which does not know how long the objects are

String handling in C is definitely the greatest weakness of the
language.

However, it is also one of its greatest strengths. Yes, I know this is
heresy in the eyes of the Perl programmers, but really, the way C
handles strings may require a bit of care, but it also allows a lot of
efficiency.

Richard

 

[Kelsey Bjarnason]

[snips]

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

Okay, I don't see the problem. You created a char array - not a string,
simply a char array - and passed it to a function that expects a string.

If one insists upon passing about incorrect data, one is going to get
failures. This isn't a language issue, it's an issue of someone being
careless - not a good sign in a programmer. Or clueless, an even worse
sign.

 

[user923005]

[snips]

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

Okay, I don't see the problem. You created a char array - not a string,
simply a char array - and passed it to a function that expects a string.

The only difference between a character array and a string in the C
language is the contents.
This is one way in which the problem can arise (and it does happen).
It can also arise from memcpy or strcpy of one char too far, assigning
the last char to a non-zero value, and a host of other ways.

If one insists upon passing about incorrect data, one is going to get
failures. This isn't a language issue, it's an issue of someone being
careless - not a good sign in a programmer. Or clueless, an even worse
sign.

It is a sign of a defect in the language. That many C programmers
refuse to see this is simply unbelievable.

If there were not literally BILLIONS of dollars of damage caused by
this defect, then the defenders would have a leg to stand on.
These problems are not always due to carelessness. They are also due
to malice.

I have seen (for instance) scanf() or sscanf() used with %s used for
reading a string, written by good programmers. This is (of course)
exactly the same danger as gets(). Herein lies the problem: They are
assuming that the program's users are sensible people who are not out
to harm anyone. In reality, this is true for 99.9999% of the users.
But that one tiny fragment on the end is out to cause harm.

It's kind of like making armor, with a great big opening over the
heart. "But people should't stab you in the heart! That's not very
nice!" Well, yes, but that's the whole point of armor.

I also think that dangerous constructs are (to some degree)
unavoidable to C. But to say that these things are not dangerous is
really putting our head in the sand.

One could also say that an unsheathed sword is not dangerous. After
all, if we do not weild it in a malevolent or incompetent manner,
nobody is going to get hurt (unless they fall on it themselves). But
in reality a sword *is* a dangerous thing because it requires *great
and competent care* not to harm someone with it. Pretending there is
no danger attached to a sword does not make it safer. If anything, it
will make it more dangerous. Pretending that C does not have
dangerous (or even badly designed) things is also something that
encourages carelessness. The very thing we want to avoid in the
utmost.
IMO YMMV.
But if you think differently, then YOIW.

 

[Kenneth Brody]

[snips]

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

Okay, I don't see the problem. You created a char array - not a string,
simply a char array - and passed it to a function that expects a string.

If one insists upon passing about incorrect data, one is going to get
failures. This isn't a language issue, it's an issue of someone being
careless - not a good sign in a programmer. Or clueless, an even worse
sign.

It's "dangerous" in that a newbie doesn't see the difference between:

char token[6] = "123456";
and
char token[] = "123456";

After all, they only see 6 chars in both.

And, as far as the compiler is concerned, both can be passed to
strstr() without issue.

However, a language that prevents a newbie from doing anything that
you can call "dangerous" is also not going to allow an experienced
programmer from doing anything beyond newbie-stuff.

With power comes responsibility.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Keith Thompson]

I have seen (for instance) scanf() or sscanf() used with %s used for
reading a string, written by good programmers. This is (of course)
exactly the same danger as gets().

[...]

A "good" programmer would not use scanf() with "%s".

Actually, it's probably a little harsh to judge someone as not being a
"good programmer" because of one mistake, even a serious one. But it
certainly is a mistake, and one that should be corrected both in the
code and in the programmer's habits.

(sscanf() could be a different story, since the data being scanned is
under the control of the programmer.)

 

[user923005]

The C language strings are clearly a danger. The literal billions of
dollars in damage caused by careless use of strings is a clear
indication of that fact. It is possible to design strings that know
how big they are and protect themselves from over-writes. Other
languages have this feature. Of course the cost is that these strings
are not fast like C strings.

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

The fact that it is so insidious made the C++ people choose this as
something that simply had to be fixed and could not be passed on as
allowed in the new language.

You just said a few minutes ago anyone can be a C programmer in
a month. While you are not in error here, your argument isn't
consistent.

No, I said the O.P. can become competent enough for junior projects in
a month. And I did not say anyone could do it. There are clearly
people who are not cut out to be programmers. If you want to
attribute something to me, why not quote it from my message? If you
take an actual quote, then there is less chance for misapplication.

 

[user923005]

[snips]

Here is a C language feature that is dangerous which has to do with
strings:
static const char token[6] = "123456";
...
if (strstr(string, token) != NULL) puts("found it.");

Okay, I don't see the problem. You created a char array - not a string,
simply a char array - and passed it to a function that expects a string.

If one insists upon passing about incorrect data, one is going to get
failures. This isn't a language issue, it's an issue of someone being
careless - not a good sign in a programmer. Or clueless, an even worse
sign.

It's "dangerous" in that a newbie doesn't see the difference between:

char token[6] = "123456";
and
char token[] = "123456";

After all, they only see 6 chars in both.

And, as far as the compiler is concerned, both can be passed to
strstr() without issue.

However, a language that prevents a newbie from doing anything that
you can call "dangerous" is also not going to allow an experienced
programmer from doing anything beyond newbie-stuff.

That has not been demonstrated.

With power comes responsibility.

It's dangerous because it's dangerous.

We are not talking about newbies. The buffer overrun virus attacks
that have caused billions of dollars of damage attacked code written
by experienced programmers.
If Grand Coulee dam burst, the damage would be in billions. We would
call something that might do that "dangerous".
There have been billions of dollars of damage caused by C buffer
overruns. These programs were not written by newbies but by people
with decades of experience.
I can show you literally dozens of posts -- written in this forum by
experts respected by all -- that contain buffer overrun exploits.
There is no debate as to whether the construct is dangerous or not.
The fact that it has caused billions of dollars of damage means that
it *is* _by definition_ dangerous.
C strings are a bad design, and reliance upon a zero byte to terminate
them is bad.
Now, it's OK for a language to have bad features. Every language has
bad features. But to pretend that they aren't bad and don't need
attention -- that is very bad. In fact, it is worse than the defects
in the first place.

I belive that those who say that C strings are not dangerous are not
clear thinkers, or are simply so in love with C that they refuse to
look at the wart on her nose and say that it is anything less than
breathtakingly beautiful.

They are dangerous because they have caused huge, huge harm again and
again -- despite careful experts doing their best to write safe code.

From http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=dangerous

we have this:
dangerous
One entry found for dangerous.
Main Entry: dan·ger·ous
Pronunciation: 'dAn-j&-r&s; 'dAn-j&rs, -zhr&s
Function: adjective
1 : exposing to or involving danger <a dangerous job>
2 : able or likely to inflict injury or harm <a dangerous man>
- dan·ger·ous·ly adverb
- dan·ger·ous·ness noun
synonyms DANGEROUS, HAZARDOUS, PRECARIOUS, PERILOUS, RISKY mean
bringing or involving the chance of loss or injury. DANGEROUS applies
to something that may cause harm or loss unless dealt with carefully
<soldiers on a dangerous mission>. HAZARDOUS implies great and
continuous risk of harm or failure <claims that smoking is hazardous
to your health>. PRECARIOUS suggests both insecurity and uncertainty
<earned a precarious living by gambling>. PERILOUS strongly implies
the immediacy of danger <perilous mountain roads>. RISKY often applies
to a known and accepted danger <shied away from risky investments>.

Billions of dollars in damage would amount to "harm or loss". Much of
this harm or loss is caused by C buffer overrun exploits. By
definition, C strings are dangerous.

 

[user923005]

[...]> I have seen (for instance) scanf() or sscanf() used with %s used for

reading a string, written by good programmers. This is (of course)
exactly the same danger as gets().

[...]

A "good" programmer would not use scanf() with "%s".

That's false, because good programmers have done it. It's not common,
but it happens.

Actually, it's probably a little harsh to judge someone as not being a
"good programmer" because of one mistake, even a serious one. But it
certainly is a mistake, and one that should be corrected both in the
code and in the programmer's habits.

No argument there.

(sscanf() could be a different story, since the data being scanned is
under the control of the programmer.)

It is also possible to err even with sscanf() though there is an added
layer of safety.

In closing, I would like to post the following:

Lawrence Kirby
Newsgroups: comp.lang.c
From: (e-mail address removed) (Lawrence Kirby)
Date: Wed, 9 Feb 1994 01:36:40 +0000
Local: Tues, Feb 8 1994 6:36 pm
Subject: Re: scanf question
Reply to author | Forward | Print | Individual message | Show original
| Report this message | Find messages by this author

#include <stdio.h>
main()
{
FILE *fp;
char *ch;
fp = fopen("test.dat","r");
fscanf(fp,"%s",&ch);
fprintf(stderr,"%s",ch);
}

The above program complains segmentation fault and consequently core dump.
When I use fscanf(fp, "%c",&ch) it works fine. Can anyone tell me what is
wrong? Thanks a lot!

Your passing fscanf() a pointer to a pointer to char. So you're
expecting
it to write a string into a pointer. This results in undefined
behaviour.
Even if it survives that the pointer won't contain a sensible pointer
value
so when you pass it to fprintf it is likely to access any old bit of
the
address space which would probably result in a segmentation fault. You
need to define somewhere to put the string (i.e. a character array)
and
then pass a pointer to it to to fscanf() and fprintf(). Since the
'value'
of an array is a pointer to its first element this becomes:

#include <stdio.h>
main()
{
FILE *fp;
char buffer[20]; /* Pick a suitable buffer size */
fp = fopen("test.dat","r");
if (fp != NULL) { /* If the fopen() failed your
program
would probably have crashed */
fscanf(fp,"%s",buffer);
fprintf(stderr,"%s",buffer);
}
return 0; /* You should return a value from
main */

}

-----------------------------------------
Lawrence Kirby | (e-mail address removed)
Wilts, England | (e-mail address removed)
-----------------------------------------

Now, Lawrence Kirby was not only familiar with the problem of buffer
overrun with scanf() of fscanf() combined with %s, but he often
counseled against it. Certainly, this is not some polished work that
he did and neither was it his original work, but rather a correction
of someone else's work. But if such an attrocity can escape from the
fingers of one Lawrence Kirby, then it can escape from the fingers of
us all.

You will find other scintillating stars of c.l.c also guilty in this
regard.

 

[Keith Thompson]

[...]> I have seen (for instance) scanf() or sscanf() used with %s used for

reading a string, written by good programmers. This is (of course)
exactly the same danger as gets().

[...]

A "good" programmer would not use scanf() with "%s".

That's false, because good programmers have done it. It's not common,
but it happens.

[...]

Define "good programmer".

Here's a proposed definition: A "good programmer" is one who never
uses scanf() with "%s".

And yes, that's a gross exaggeration. All programmers, even good
ones, make mistakes, and I don't seriously mean to denigrate the
anyone's skills.

But I know of no programming language in which it is particularly
difficult to write bad code.

 

[user923005]

[...]> I have seen (for instance) scanf() or sscanf() used with %s used for
reading a string, written by good programmers. This is (of course)
exactly the same danger as gets().
[...]
A "good" programmer would not use scanf() with "%s".

That's false, because good programmers have done it. It's not common,
but it happens.

[...]

Define "good programmer".

Here's a proposed definition: A "good programmer" is one who never
uses scanf() with "%s".

And a good driver never runs a stop sign or exceeds the speed limit.
And a good husband never yells at family members.
And a good lawyer always wins his cases when he is in the right.
But all of us can (and do) make mistakes.

And yes, that's a gross exaggeration. All programmers, even good
ones, make mistakes, and I don't seriously mean to denigrate the
anyone's skills.
Right.

But I know of no programming language in which it is particularly
difficult to write bad code.

I agree. Every language can be used to write bullet-proof treasures.
Every language can be used to write haphazard slop.

I happen to like the C language very much. However, when I see a
fault, I don't say "That's not a fault." Instead, I say "Yes, it's a
defect. So here is how we work around it..."
In fact, you (and all the other C supporters) have been doing the very
same thing. They have been saying "If you are really smart and really
careful you will avoid mistakes." This is (of course) the basic
definition of smart and careful. But no matter how smart or how
careful you are, mistakes are possible. The possibility of error does
not render a tool useless. After all, even a skilled craftsman will
peg himself with a hammer once in a blue moon. I still want my house
built, and I still want a craftsman, and I even still want him to use
the hammer. But when we come to a tool with lots of sharp edges and
that occasionally emits showers of sparks, I want to mention that this
tool is 'dangerous' and even that it might not be a bad idea to think
about ways of improving the tool.

There are no ideal computer languages. C is a very good one because:
1. It is easy to learn
2. It is very efficient
3. It has a certain terse elegance

On the other hand, the C language is not without faults. It is a good
thing to admit to these faults. It is even better to help others
avoid the dangerous bits by explaining the dangers. And it is
ultimately good to eventually repair all of the faults.

IMO-YMMV.

 

[Richard Heathfield]

user923005 said:

The only difference between a character array and a string in the C
language is the contents.

Not so. Here's another difference, just to prove my point: there is no
string type in C, whereas there are plenty of character array types.

Now, your "only difference" is a very important difference. strstr
requires a string as input. If you give it something that is not a
string, I fail to see how this is the fault of strings, since no
strings are involved. What you seem to be saying is that it's dangerous
*not* to use strings.

Yes, buffer overrun exploits are a problem in C, but this has about as
much to do with strings as red light violations have to do with cars.
The car itself is not actually the problem.

 

[user923005]

user923005 said:



Not so. Here's another difference, just to prove my point: there is no
string type in C, whereas there are plenty of character array types.

Right. A serious defect to be sure.

Now, your "only difference" is a very important difference. strstr
requires a string as input. If you give it something that is not a
string, I fail to see how this is the fault of strings, since no
strings are involved. What you seem to be saying is that it's dangerous
*not* to use strings.

I have already agreed that the difference between a string and an
array is the contents.

Yes, buffer overrun exploits are a problem in C, but this has about as
much to do with strings as red light violations have to do with cars.
The car itself is not actually the problem.

Cars also kill people from time to time. There are some things about
cars that are clearly unsafe. If the brakes are bad and you hit
someone in a car you borrowed, it was not the driver but the car.
C strings are the bad brakes in the C language.
To pretend that they are not a problem despite the billions of dollars
of damage that has been done directly due to their use by highly
intelligent programmers is a disservice to those who wish to
understand the language.

An acetylene torch is a dangerous thing. You can do lots of wonderful
things with it. Maybe, if it was safer, it would be a lot harder to
get the work done. But when someone comes along and wants to learn
how to weld, I think it prudent to tell the welding student that the
yellow (and sometimes blue) thing that comes out of the end of the
torch is dangerous. If we tell them that it is completely safe, then
we are lying. Not only that, but they are far more liable to damage
of some sort than if properly instructed.

To tell anyone that C strings are safe is a fabrication because the
evidence proves that they are very, very dangerous.
C strings are a box of sweating dynamite. If I said that anything
else had caused billions of dollars of damage in the hands of experts
who were trying their very best not to damage anything, I think you
would admit that it was dangerous.

Look, there's this girl. Both of us think she's amazing. She's
highly intelligent with a quick wit, and pleasant to look at. She has
beautiful flowing hair, is a wonderful conversational master and is
highly athletic. But when something funny happens, she laughs like a
donkey.
Now, that does not change anything about how we feel about her. We
look past the donkey-laugh because of all the other wonderful
qualities. But let's not pretend the donkey-laugh is the best
sounding laugh we ever heard. It's OK for something to be imperfect,
especially if it is possible to change it.

Clearly, C strings are a problem because of all the damage they
cause. If it was only a million dollars here or there, we could say
"Heck, it's only a few million." But despite recognition of the
problem and decades of work trying to clean it up, we still have
billions and billions of dollars of damage flooding forward with no
end in sight. Why not just admit the problem and say, "C strings can
cause problems, even with good programmers because we all make
mistakes. Maybe we should take a look at ways to improve things."

I guess we will probably just end up having to disagree about it.
Quite frankly it is so plain to me that I really cannot imagine how it
is possible to think that they are not a problem. But my opinion is
no better than anyone else's and it is always possible that it is me
who hasn't quite got it right.

 

[Bill Pursell]

user923005 said:



Not so. Here's another difference, just to prove my point: there is no
string type in C, whereas there are plenty of character array types.

Note the phrase: "there is no string type in C".

Now, your "only difference" is a very important difference. strstr
requires a string as input.

I'm confused....if there is no string type in C, but strstr
requires a string as input, then what exactly is it that
strstr is expecting as input? For the most part,
I agree that C has no string type, but I also agree
that strstr takes a string as an argument. Someone
(I believe user923005) said else thread that strings
in C are a problem and a reasonable person would
recognize them as being a problem and say "here's
how we work around it." I think it's more accurate to
say that the lack of any support for strings is an aspect
of the language (no judgment on whether it's good or
bad intended) and the "workaround" was to use the
English word "string" to refer to any null-terminated
character array, and all sorts of problems have
followed because of that decision.

If you give it something that is not a
string, I fail to see how this is the fault of strings, since no
strings are involved. What you seem to be saying is that it's dangerous
*not* to use strings.

Yes, buffer overrun exploits are a problem in C, but this has about as
much to do with strings as red light violations have to do with cars.
The car itself is not actually the problem.

I agree (almost). Buffer overrun exploits are a problem in computers.
Programs which are built from C are more prone
to them because the C language provides less protection than
do other languages. Else-thread, the analogy of a suit of
armor with a hole over the chest was given, and this is exactly
the wrong analogy. C isn't armor. It doesn't claim to be armor,
and it never claimed to be armor. It's a tool. If you want armor,
you'd be pretty stupid to strap a hammer on your chest and
complain that it doesn't protect you adequately.

 

[Richard Heathfield]

user923005 said:

I guess we will probably just end up having to disagree about it.

I guess you're right there, at least. You see, your analogies don't work
for me.

Quite frankly it is so plain to me that I really cannot imagine how it
is possible to think that they are not a problem.

And likewise, I can't imagine how it is possible to think that they are
- except that I know my good friend user923005, whose opinion I
respect, considers them to be a problem. But, whilst I take your
opinion seriously, I can't bring myself to agree with it. Strings are
not dangerous, and that's flat. Yes, I will grant that there are some
tools around that don't do their job very well (e.g. gets(),
scanf("%s", s) etc), but to blame strings for that is to miss the
point, I feel.

But my opinion is
no better than anyone else's and it is always possible that it is me
who hasn't quite got it right.

Your opinion *about C* carries a fair amount of weight compared to most
other people's, because it is evident that you have studied the
language in depth. Nevertheless, on this occasion I cannot agree with
you. That may, of course, mean that I'm wrong and you're right. But
obviously I don't think so (otherwise I'd have changed my mind!).

 

[Richard Heathfield]

Bill Pursell said:

I'm confused....if there is no string type in C, but strstr
requires a string as input, then what exactly is it that
strstr is expecting as input?

A string. That is, a sequence of characters terminated by the first null
character.

 

[user923005]

Bill Pursell said:



A string. That is, a sequence of characters terminated by the first null
character.

The point Richard was making was that there is no object type of
string in C.
The word string is used freely in K&R and in the standard, but never
in reference to a type.

A string is really a convention. We decide that an array that has a
zero element in it will describe a string of data.

We could say that C has a language feature of strings. But those
strings are not really types.

 

[Keith Thompson]

I'm confused....if there is no string type in C, but strstr
requires a string as input, then what exactly is it that
strstr is expecting as input?

[...]

strstr() takes two arguments, of course.

Each argument must be a char* (a type, enforced at compile time) *and*
each argument must point to a string (a data format, not enforced at
compile time). If you try to give it something other than a char*,
your program won't compile. If you give it a char* that doesn't point
to a string (either because it doesn't point to *anything*, or because
it points to something other than a string) you invoke undefined
behavior.

A "string" is, by definition, "a contiguous sequence of characters
terminated by and including the first null character". It's a data
format, not a data type.

 

[websnarf]

[...]> I have seen (for instance) scanf() or sscanf() used with %s used for
reading a string, written by good programmers. This is (of course)
exactly the same danger as gets().
[...]
A "good" programmer would not use scanf() with "%s".

That's false, because good programmers have done it. It's not common,
but it happens.

[...]

Define "good programmer".

Here's a proposed definition: A "good programmer" is one who never
uses scanf() with "%s".

And yes, that's a gross exaggeration.

Yes, but why is this or any other definition of a good C programmer so
esoteric? And why does a bad C programmer cost the industry billions,
while a bad Java programmer costs the industry far less?

[...] All programmers, even good
ones, make mistakes, and I don't seriously mean to denigrate the
anyone's skills.

But I know of no programming language in which it is particularly
difficult to write bad code.

So all code is bad in an equivalent way?

I know of no programming language (besides C++ and other C variants)
even *CLOSE* to C in its level of danger (especially with regards to
buffer overflows) and undefined behavior. (Note here that assembly
language is *far* safer by this measure.)

Besides, I doubt you have tried Python. It actually *IS* hard to
write bad code in Python -- at least not if you are at least *some*
kind of a programmer. You have to write a few functions and mismatch
types intentionally before you run into anything you could call a
typical anomaly.

But at the end of the day, one can see that there is a technical
equivalency between C and Ada or Pascal on the ability to dereference
dead pointers or leak memory or whatever. So why is C so ridiculously
more unsafe that those languages?

You can't claim C's strings are more powerful than alternatives. My
bstring library puts the C standard functions to shame in terms of
power: 1) You cannot make reference based non-tail substrings of a C
string without modifying it 2) You cannot call any mutating C string
library function calls with aliased string parameters (unless you
consider memmove a string function). 3) The C library has no way of
emulating a file on top of a string (available as an extension in gcc,
but as a portable abstraction in Bstrlib). 4) C strings cannot
contain arbitrary binary contents ('\0' is always a terminator) so a C
string cannot hold both the input and output of encrypted or
serialized data streams. But of course my library is written *in C*
so you can't claim that the C language found some ideal trade off --
they did nothing of the sort. C's strings are in fact *LESS* powerful
than is found in most other languages, and as Bstrlib demonstrates
that its only because C's library was badly designed.

 

[Clem Clarke]

Obviously, there are two streams of thought here, those that think there
is a problem, and those that don't. And some people think that there is
a C string type.

Those that say there isn't a problem, and that it is the programmer's
fault perhaps have forgotten that seat belts were introduced into cars
(and variable crumple rates) to protect people if an accident happens.
It is true that an accident is caused by cars (well, most cars...) but
rather the driver. And it is precisely because drivers do cause
accidents, we have safer cars. Indeed, cars handle much better than
they used to, and have many more safety features built in. And computer
languages should be safer, rather than not (safer). We ALL make mistakes!

And for those people that suggest that C does have a string type, I
would suggest that it doesn't, compared with Pascal, PL/I, COBOL or even
Assembler. It has an array of characters, which is quite different from
a string.

For example, in PL/I, one could write:

Dcl String10 char(10) varying;
Dcl String20 char(20) varying init
('Long 20 Character XX');


String10-string20;

This will automatically truncate the result, rather than copy the 20
bytes and overwrite adjacent storage, as in C.

And so naturally, I agree with those that say there is a problem.


What is needed is for ANSI to bite the bullet and fix the problem. Or
for someone big, like IBM to do it, and force a standard change. (As an
aside, there is a language called D, which has a length word for
strings, I believe. It is written by Walter Bright, who wrote the
original Zortech C compilers. Bright by name, bright by nature... I
think it uses the GCC C compiler as a backend.)

But I shall write to ANSI now. Again, I think....

The thing is that there is quite a lot of straight C code making it's
way into IBM's Z/OS at the moment. And it should take into account
these performance robbing routines, because mainframes usually run
thousands of programs at once, rather than the tens or hundreds that a
Linux box might. Therefore, overheads need to be kept to a minimum (as
they should always be...).


Clem