C (functional programming) VS C++ (object oriented programming)

[Richard Heathfield]

Tor Rustad said:

My point was, what you called a "mistake", is rather what rest of the
world call these functions, namely "string functions".

So the rest of the world gets it wrong. Why does this not surprise me?
Sturgeon's Law, and all that.

Since "str" is a shorthand for "string", it is pedantry to me, calling
it a *mistake* of the paper, and using the C standard (which is
responsible for the shorthand) to argue otherwise.

Yes, it's pedantry. That's what programmers *do*. We have to, because
that's what computers do, too. If you think I'm cut to the quick by being
called a pedant, think again.

When you as a c.l.c regular state:

"Finding other mistakes is left as an exercise for the reader."

I expect a low-class paper with real technical issues,

Right, and when I find a mistake in the very first sentence, that's what I
expect too.

not that you referred to some common practice wording.

"Common practice" doesn't mean the same as "correct".

 

[Richard Heathfield]

Charlie Gordon said:

strtok and gets also do what they are documented to do, yet you agree
they should be deprecated.

I'll agree for gets, since it cannot be used correctly. I don't see what
you've got against strtok, though.

strncpy is so easy to misuse and so widely misused that it should be more
actively scrutinized.
A compiler warning seems appropriate for all of them.

Fine, if you like noisy compilers. To me, not even the "you have used gets"
diagnostic message that my implementation issues is particularly valuable,
since either I haven't used gets (in which case the message doesn't appear
at all), or I have deliberately used it for the sake of making a point, in
which case I know perfectly well that I've used it and do not need to be
reminded. Nevertheless, I can understand why it's there. But, in general,
diagnostic messages on stylistic grounds seem noisy to me. I see no reason
to diagnose strncpy or strtok.

 

[santosh]

Charlie Gordon said:
<snip>

Fine, if you like noisy compilers. To me, not even the "you have used
gets" diagnostic message that my implementation issues is particularly
valuable, since either I haven't used gets (in which case the message
doesn't appear at all), or I have deliberately used it for the sake of
making a point, in which case I know perfectly well that I've used it and
do not need to be reminded. Nevertheless, I can understand why it's there.
But, in general, diagnostic messages on stylistic grounds seem noisy to
me. I see no reason to diagnose strncpy or strtok.

I agree here. Just one day of lurking in this group ought to convince any
beginner to C to avoid gets like hell and to be very careful with strtok.
These functions are discussed repeatedly, though granted strncpy is quite a
bit more obscure.

 

[Joe Mayo]

I think I will prefer C anyway, because it has a simpler syntax and less
internal keywords to learn than C++. I prefer easy solutions.

"simpler syntax and less [1] internal keywords" doesn't (necessarily) mean
"easier", which IMAO is more to do with how well things compose and
co-operate that it is to do with the size of the syntax.

Of course a cumbersome syntax can doom a straightforward idea, but no-
one would /ever/ do that in a modern programming language.

[1] /fewer/.

I saw alread C++ projects, where I spent much more time on understanding
the C++ keywords and how the templates worked than the code itself!

Finally C is similar to C++ with the difference that in C there are no
private members, but normally private variables and functions are named
with the prefix underscore "_", so its very clear.

The second difference is that C has no templates, but I never really
needed it.

 

[Richard]

strtok and gets also do what they are documented to do, yet you agree they
should be deprecated.

I dont agree any suhc thing. But they are fatally flawed.

strncpy is so easy to misuse and so widely misused that it should be more
actively scrutinized.

You are either a very bad programmer or a troll. Sorry but strncpy does
what the documentation says. The fact that you seem unwilling or
incapable of using it correctly has become a tad boring to be honest.

A compiler warning seems appropriate for all of them.

Bullshit. Would you like a compiler warning when incrementing a pointer
too in case the programmer forgets to keep it pointing to valid memory?

 

[Al Balmer]

We should differentiate between *dynamic* strings, and *fixed-sized*
strings. The strl* functions was designed for fixed-sized strings, if
you want to handle strings dynamically, I suggest you to use some
another API's for that.

Maybe I'm missing something, but I class that reply as non-responsive.

Let me simplify further - Why the assert rather than the conventional
return?

 

[Al Balmer]

And it seems to me, you are living on a different planet.
Pick and read samples from real world C programs that use the stinker and
see for yourself how inappropriate the function is for most of the cases.

I've been doing that for more than 20 years. It's not been my
experience that "so few programmers" are able to read and understand
the description of strncpy.

The programmers you know, if they can't be educated, should not be
programming.

http://www.google.com/codesearch?q=strncpy+sizeof

You can also look at misuses in the glibc source itself.

I'm sure that I could find misuses of many library functions,
including strncpy. Why don't you propose a subset of the C language
which cannot be misused?

 

[Chris Thomasson]

Minimalist Interfaces For C:

http://groups.google.com/group/comp.lang.c/browse_frm/thread/1b106926ba5db19f

 

[Malcolm McLean]

I'm sure that I could find misuses of many library functions,
including strncpy. Why don't you propose a subset of the C language
which cannot be misused?

Can be misused and invite misuse are too different things.

 

[Malcolm McLean]

I dont agree any suhc thing. But they are fatally flawed.

But in practise people are always "correcting" use of gets with misuses of
fgets(). gets cannot be used safely except when caller controls stdin, but
it can be implemented safely. A safe implementation would be one that always
terminates with an error message on buffer overrun.
Most real implementations are not perfectly safe, but they are reasonably
safe, and you have to be either very unlucky or malicious to get anything
other than a segfault. On the other hand no compiler can ever correct faulty
handling of truncated lines, if the the program is perfectly well-defined as
the C standard sees it.

gets() should go, but fgets() is the real danger, and is especially
dangerous because, even when the threat is pointed out, even experienced C
programmers are very slow to recognise it.

 

[santosh]

But in practise people are always "correcting" use of gets with misuses of
fgets().

How so?

gets cannot be used safely except when caller controls stdin, but
it can be implemented safely. A safe implementation would be one that always
terminates with an error message on buffer overrun.

A "safe" implementation of gets would no longer be gets, but another
function.

Most real implementations are not perfectly safe, but they are reasonably
safe, and you have to be either very unlucky or malicious to get anything
other than a segfault.

Do bear in mind that certain system do not have memory protection
mechanisms, and even in those that do, a segfault for something as
simple
as reading a line of input is unacceptable.

As you note, gets as defined by the Standard can only be used safely
if the
program controls the behaviour of stdin completely. Since this is
almost
never the case, gets can almost never be used safely.

On the other hand no compiler can ever correct faulty
handling of truncated lines, if the the program is perfectly well-defined as
the C standard sees it.

This is programming issue to be sorted out by the programmer. Nothing
the
compiler should interfere with.

gets() should go, but fgets() is the real danger, and is especially
dangerous because, even when the threat is pointed out, even experienced C
programmers are very slow to recognise it.

IMHO fgets is not dangerous. It may be prone to misuse, like strncpy
and
strtok, but then almost any Standard library function can be misused,
if
you try hard enough. C is not a "safe" language, it was never meant to
be.

 

[Flash Gordon]

Malcolm McLean wrote, On 06/10/07 08:08:

But in practise people are always "correcting" use of gets with misuses
of fgets(). gets cannot be used safely except when caller controls
stdin, but it can be implemented safely. A safe implementation would be
one that always terminates with an error message on buffer overrun.

Extremely difficult to implement. You would have to make all your
pointers "fat" pointers that include in some manner the amount of space
available from the point the pointer points to (note the pointer might
point in to the middle of a buffer, and this is not actually *that*
uncommon on input routines).

Most real implementations are not perfectly safe,

True. Most are completely unsafe.

but they are
reasonably safe, and you have to be either very unlucky or malicious to
get anything other than a segfault.

Well, we never see malicouse code exploiting the use of gets...

Oh, wait a moment, there have been a number of cases where it *has* been
exploited in the real world. Since it gets exploited in the real world
malicious code is obviously a real problem. For a lot of people a
"segfault" is also a real problem.

OK, so that demonstrates the first half of your claim is wrong and gets
is unsafe.

On the other hand no compiler can
ever correct faulty handling of truncated lines, if the the program is
perfectly well-defined as the C standard sees it.

Yes, which means the behaviour is consistent and easy to debug. If your
testing is so bad that it does not include such obvious things
over-length input then you need to go back to basics and learn how to
test. Note that gets might well *not* crash or show any bad effects on
over-length input but still be exploitable, where as fgets will give
consistent behaviour. The only way to ensure all bad uses of gets are
caught is not testing but ensuring that there is NO use of gets.

gets() should go,
Yes.

but fgets() is the real danger, and is especially
dangerous because, even when the threat is pointed out, even experienced
C programmers are very slow to recognise it.

Actually, experienced programmers can use it safely. You just check the
return value (as you always should with an input function in any case)
and check if a complete line was read. If a complete line was not read
you do whatever your requirement spec says you should do.

People get it wrong sometimes, even experienced programmers. However
there is always a risk of a mistake being made whatever facility is used.

 

[jacob navia]

Can be misused and invite misuse are too different things.

Example:

int SetCustomerName(Customer *pCustomer, char *name);

....

SetCustomerName(pCustomer,"John Smith");

//Segmentation Fault.

Why?

In the documentation of the function footnote 3 we read:

The customer name must be preceded by its Social Security number.
like "334465644\tJohn Smith". If this is not the case, the
behavior is undefined.

Programmer: But this is CRAZY!

Answer:
C is like that. If you do not want C use Java.

 

[Tor Rustad]

Maybe I'm missing something, but I class that reply as non-responsive.
Let me simplify further - Why the assert rather than the conventional
return?

You should do input checks at *entry* of the *calling function*, and I
advocate that if this is done properly, truncation should never happen
in correct code (context here is fixed-sized strings).

The assert simply trap such programming faults.

I see the return value of strl*, as a mechanism for dynamic string
management, i.e. it provide information for error-recovery via realloc.

However, for fixed sized strings, there is no recovery via reallocation
available, so many people will just ignore the strl* return value anyway.

To summarize: the assert stop the programmer from converting
buffer-overflow bugs, into truncate bugs.


--
Tor <torust [at] online [dot] no>

"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies"

 

[Charlie Gordon]

The problem is that people think it is a general purpose safe or
sub-string strcpy() replacement.
It isn't. It is designed for copying strings to fixed length database
fileds where there is no necessary terminating nul and no random padding
characters are allowed. For that purpose it is exactly what you wnat.

That purpose is very rare indeed.
For the more general pourpose of safe or sub-string strcpy replacement, one
or more standard string function are needed with well chose semantics and
appropriate names. Let's first deal with that.

 

[Charlie Gordon]

Tor Rustad said:



...which I don't need and don't use.

That's surprising, because I have rarely seen a project where the need for
safe or sub-string copy did not surface one way or another.

I don't need or use those, either.

I agree here, because I don't want a dinky string utility function to call
error handlers in my back. I just want precise semantics, a simple intuitive
API, and and easy want to test for truncation in the places where it
matters.

 

[Charlie Gordon]

A well designed API, should be consistent and simple. There are quite some
years ago now, when I told c.l.c people, that the better alternative for
strncpy() and strncat(), was provided by OpenBSD strlcpy() and strlcat().

Apparently, the standards people didn't agree, so now we have strcpy_s()
and strcat_s().

strlcpy and strlcat provide a consistent API for string copying and
concatenating with truncation. Truncation is part of the API, it can be
detected easily wherever it is inappropriate:

if (strlcpy(dest, src, dest_size) >= dest_size) {
/* truncation occurred, deal with it */
}

This behaviour is consistent with that of snprintf (too bad the order of
arguments is not).

Many if not most instances of strncpy in real life programs attempt to do
precisely what strlcpy does per design.

On the other hand, the "safe" string functions strcpy_s and strcat_s address
a different purpose: They are drop-in replacements for strcpy and strcat,
provided the size of the destination arrays is known at the point of
replacement, and they will detect overflow and NULL pointers that would
definitely cause undefined behaviour for strcpy and strcat. valgrind, where
it is available, can do much of the same work without the need to alter the
source code. Other debugging tools try and address these issues.

Both issues should be addressed in the standard, but they are independent of
one another.

 

[Richard Heathfield]

Charlie Gordon said:

That's surprising, because I have rarely seen a project where the need
for safe or sub-string copy did not surface one way or another.

I didn't say I had no need for safe or sub-string copy. I said I had no
need for strlcpy() and strlcat().

 

[Peter 'Shaggy' Haywood]

Groovy hepcat jacob navia was jivin' in comp.lang.c on Wed, 3 Oct 2007
8:36 am. It's a cool scene! Dig it.

Ahhh but it was a JOKE!

Jut a JOKE!

You didn't find it FUNNY?

Jacob, I think you need to study the following definitions.

Humour: (something having) the quality of causing amusement. The
faculty of expressing or appreciating what is comic or amusing.

Sour grapes: an (ironic or sarcastic) expression of bitterness or
hatred. Nastiness.

 

[Malcolm McLean]

That purpose is very rare indeed.
For the more general pourpose of safe or sub-string strcpy replacement,
one or more standard string function are needed with well chose semantics
and appropriate names. Let's first deal with that.

I've never worked on a database-intensive program.
However I suspect it has become obsolete. There are advantages in having
short fixed fields; for instance often a compare can be done by casting to
wide integer and performing a single instruction. This only works if padding
is specified as zero.
However nowdays everything would be managed by an sql box and that sort of
consideration is getting out of date. So strncpy() has a declining niche.