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

[Keith Thompson]

You may be right about what he meant, but let's not forget that
"functional" is a standard English word, and "functional way" may not
refer to functional programming.

The subject header is:

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

It seems clear that the OP is simply using the technical term
"functional programming" incorrectly, where he should have used
"procedural programming".

 

[Tor Rustad]

[...]


Even GCC decided not to add it

Did you follow the GNU discussion back then? IIRC, the main argument
against it, was that few C programmers, demanded these functions and
that rolling your own would be easy.

Only sporadically, since I didn't have any strong feelings either way.
I remember claims that there was no evidence that they made things
safer, despite their long history in BSD,

IMO, security wise, OpenBSD track record is rather good. OpenBSD homepage:

"Only two remote holes in the default install, in more than 10 years!"

As a security professional, I prefer to talk about higher assurance
level, rather than "safer". Safety and security, isn't the same thing.
Assurance level increase, when performing code audit, using more robust
& simpler API etc.

and that it's better for
programmers to be aware of how long their strings are, rather than
having to check whether data was truncated. I certainly agree with the
last, since programmers who can't properly handle strings are probably
among those who never check return values

I find that argument was rather silly.

In particular library developers, should know how to write
post-conditions. My own strlcpy() and strlcat() implementation from 7
years ago, had assert() in place, to detect truncation.

I can't remember, ever being hit by a truncation bug, after the module
test phase.

A little while ago, I was asked to enhance a Windows program I wrote a
few years ago. An upgrade to the latest Visual Studio was required, as
well. One of our regular Windows programmers was happy to tell me how
to turn off the warnings about not using the *_s functions <G>.

A simple #pragma warning (disable: NNN) should do.

With the latest VC++, I couldn't figure how to create a simple console C
project, without those C++ files being generated. :-(

So, I still use VC++ 6, when possible.. less bloated and no *_s warnings.

 

[Tor Rustad]

Charlie Gordon said:



I'm all for fixing incorrect usages of strncpy, but it's not strncpy's
fault if it's misused.

Fixing the disease for one patient, doesn't lead to a healthy world.


The smarter method, is to use simpler & better interfaces. For those
interested, look up the paper "strlcpy and strlcat -- consistent, safe,
string copy and concatenation." by Todd C. Miller, Theo de Raadt.
(USENIX 1999)

 

[Al Balmer]

Al Balmer wrote:
[...]


Even GCC decided not to add it
Did you follow the GNU discussion back then? IIRC, the main argument
against it, was that few C programmers, demanded these functions and
that rolling your own would be easy.

Only sporadically, since I didn't have any strong feelings either way.
I remember claims that there was no evidence that they made things
safer, despite their long history in BSD,

IMO, security wise, OpenBSD track record is rather good. OpenBSD homepage:

"Only two remote holes in the default install, in more than 10 years!"

I'm only recalling the argument. Of course, the fact that BSD is
relatively secure is not necessarily due to the use of strlcpy.

As a security professional, I prefer to talk about higher assurance
level, rather than "safer". Safety and security, isn't the same thing.
Assurance level increase, when performing code audit, using more robust
& simpler API etc.



I find that argument was rather silly.

In particular library developers, should know how to write
post-conditions.

It has nothing to do with the library, but with the people using it.

My own strlcpy() and strlcat() implementation from 7
years ago, had assert() in place, to detect truncation.

? truncation is a *feature* of the current implementation. If
truncation is an error meriting an assert, it seems to me that prior
detection of the situation and a call to strcpy or strncpy would be
better. I'm probably missing something.

I can't remember, ever being hit by a truncation bug, after the module
test phase.





A simple #pragma warning (disable: NNN) should do.

The method recommended is a #define.

With the latest VC++, I couldn't figure how to create a simple console C
project, without those C++ files being generated. :-(

Haven't tried that. If I needed to make a console app, I'd probably
use Watcom.

So, I still use VC++ 6, when possible.. less bloated and no *_s warnings.

Beware if you ever have to move something to version 8. The conversion
wizard has holes.

 

[Al Balmer]

The subject header is:

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

It seems clear that the OP is simply using the technical term
"functional programming" incorrectly, where he should have used
"procedural programming".

Who reads headers? <g>

Given the header, you're probably right. He saw the phrase somewhere
and guessed at what it meant.

 

[Chris Torek]

Yes; but at the same time:

Fixing the disease for one patient, doesn't lead to a healthy world.

The smarter method, is to use simpler & better interfaces. For those
interested, look up the paper "strlcpy and strlcat -- consistent, safe,
string copy and concatenation." by Todd C. Miller, Theo de Raadt.
(USENIX 1999)

Indeed. Some interfaces seem inherently prone to misuse (gets(),
strtok(), and so on).

One can gripe about the Standard including those in the first place,
and many do. One can also point out that they are valid Standard
C even if they have to be used with care -- in the case of gets(),
for instance, with such extreme care that one might as well say
"never use this".

The problem is, this is really the wrong group for discussion about
error-prone-ness. If the goal is to measure the error rate of
various interfaces, the right group is probably comp.software-eng;
if the goal is to propose changes in a future C standard, the right
group is probably comp.std.c. Either way, comp.lang.c is the wrong
group.

(Of course, it *is* safe to provide and use str_lcpy and str_lcat
in comp.lang.c postings.)

 

[J. J. Farrell]

Of course!

How FUNNY!

I didn't say it was funny, though it raised a small smile.

So you approve that when somebody asks a perfectly valid question
(or even a bad question who cares) the "regulars" in c.l.c have the
right to laugh at him and recommend him to "take a bath".

Of course not, that would be extremely rude. What you describe has no
connection with what happened here, though. This was a simple case of
an almost reflex throw-away comic response to someone saying "I think
I become more and more alone...". Perhaps this is just a case of
different senses of humour, though it's more often people from the USA
who have difficulty understanding humour of this sort.

This is one of the basic tenants of group cohesion here: to laugh at the
beginner is used in all groups to solidify group cohesion against the
new participants, at the expense of the new ones that are
perceived as weaker and isolated.

There is some merit to this comment, though it applies only to to a
small number of messages from a very small number of posters. It
certainly doesn't apply in this case.

 

[Richard Heathfield]

Tor Rustad said:

Fixing the disease for one patient, doesn't lead to a healthy world.

It does, however, lead to a healthier patient.

The smarter method, is to use simpler & better interfaces. For those
interested, look up the paper "strlcpy and strlcat -- consistent, safe,
string copy and concatenation."

You lost me completely. What have they to do with our discussion about
strncpy?

 

[Richard Heathfield]

Keith Thompson said:

It's not a bad function. It's a decent function, useful in some
unusual circumstances, with a bad name.

Agreed, but it's impossible to change it, alas.

 

[Charlie Gordon]

Keith Thompson said:


Agreed, but it's impossible to change it, alas.

But it is possible to post a warning sign.
This newsgroup is read by a lot of programmers with varying degrees of
skill. The more become aware of strncpy's woes, the less likely they will
be producing buggy code using it.

 

[Charlie Gordon]

Tor Rustad said:


It does, however, lead to a healthier patient.


You lost me completely. What have they to do with our discussion about
strncpy?

IME strncpy is used by programmers who believe it has the semantics of BSD's
strlcpy.
They are wrong. Mass inoculation of a vaccine could help curb this rampant
misunderstanding.

 

[Charlie Gordon]

The problem is, this is really the wrong group for discussion about
error-prone-ness. If the goal is to measure the error rate of
various interfaces, the right group is probably comp.software-eng;
if the goal is to propose changes in a future C standard, the right
group is probably comp.std.c. Either way, comp.lang.c is the wrong
group.

Of course it is the right group to discuss shortcomings of Standard
functions, and make readers aware of subtleties they probably don't suspect.

 

[Charlie Gordon]

Charlie Gordon said:



I'm all for fixing incorrect usages of strncpy, but it's not strncpy's
fault if it's misused.

guns kill people, yet it is not their fault ;-)

The ANSI committee is at fault for including it in C89.
Arguably K&R should not have made this part of the original C library.

Advising caution about this function whose semantics are so peculiar and of
little use is a tool to reduce the number of bugs people produce with it.

Perhaps - but that is not what strncpy is for.

But so few programmers understand that.

 

[Richard Heathfield]

Charlie Gordon said:

This newsgroup is read by a lot of programmers with varying degrees of
skill. The more become aware of strncpy's woes, the less likely they
will be producing buggy code using it.

You are begging the question. All C functions can be misused. Very few
cannot be used properly, though. The only one that springs to mind is
gets(). Everything else, including strncpy, /can/ be used correctly. The
woe is not strncpy's, but that of the person who misuses it. If you're
going to talk about strncpy's woes, make sure you also talk about printf's
woes, and realloc's, and signal's, and div's, and log's, and sqrt's, and
strtod's woes. And the woes of all the other standard C functions.

If the possibility of misuse makes a function unusable, C itself is
unusable.

 

[Richard Heathfield]

Charlie Gordon said:

IME strncpy is used by programmers who believe it has the semantics of
BSD's strlcpy.

I don't base my assessment of a standard C library function on how it can
be misused, but on how it can be properly used. The fact that some people
misuse strncpy says no more about it than the misuse of printf says
anything about printf.

They are wrong. Mass inoculation of a vaccine could help curb this
rampant misunderstanding.

If people want to know what strncpy does, they have only to read the spec.
If they can't work out from the spec what the function does, then it's
probably a good idea for them not to use the function. But for those of us
who /can/ read (because we've done courses on it and everything, been
there, done that, got the A-B-C wall frieze), I see no particular problem
in using strncpy where it's appropriate.

 

[Richard Heathfield]

Charlie Gordon said:

"Richard Heathfield" <[email protected]> a écrit dans le message de


guns kill people, yet it is not their fault ;-)

Absolutely right. Same applies to motor vehicles, kitchen knives, and
indeed any other potentially dangerous tool that can be misused by humans.
So what do you want people to do - go back to the Stone Age? Or maybe -
just maybe - they can learn how to use tools properly?

The ANSI committee is at fault for including it in C89.

I disagree. That could reasonably be said about gets(), but not about
strncpy().

Arguably K&R should not have made this part of the original C library.

Arguably, right, because I'm arguing otherwise.

But so few programmers understand that.

This is very, very simple to understand, and programming is a highly
complex activity requiring considerable intelligence to do properly.
Anyone not capable of understanding that strncpy is not supposed to be
used as a "safe string copy" has no business being a programmer. If you
find such people in your place of work, fire them. They'd be far happier
in marketing, anyway.

 

[Ben Pfaff]

Charlie Gordon said:

You are begging the question. All C functions can be misused. Very few
cannot be used properly, though. The only one that springs to mind is
gets().

I'd rather have a function that makes it easy to get it right
than one that makes it easy to get it wrong. strncpy is firmly
in the latter category, since the explicit assignment of a null
terminator is required in conjunction with it in most cases.

In terms of Rusty Russell's "Hard to Misuse Interface Levels",
strncpy is level 7, but strlcpy is level 3, a significant
improvement in my opinion:
http://ozlabs.org/~rusty/ols-2003-keynote/img48.html

 

[Richard Heathfield]

Ben Pfaff said:

I'd rather have a function that makes it easy to get it right
than one that makes it easy to get it wrong. strncpy is firmly
in the latter category, since the explicit assignment of a null
terminator is required in conjunction with it in most cases.

I think the problem with strncpy is not that it is easy to get it wrong,
but that it is easy to misunderstand what it's for.

 

[Ernie Wright]

In terms of Rusty Russell's "Hard to Misuse Interface Levels",
strncpy is level 7, but strlcpy is level 3, a significant
improvement in my opinion:
http://ozlabs.org/~rusty/ols-2003-keynote/img48.html

Is that your own assessment? Rusty apparently assigns strncpy() to
level 14, in the domain of Easy to Misuse Interface Levels.

http://ozlabs.org/~rusty/ols-2003-keynote/img53.html

- Ernie http://home.comcast.net/~erniew

 

[Ben Pfaff]

Is that your own assessment? Rusty apparently assigns strncpy() to
level 14, in the domain of Easy to Misuse Interface Levels.

http://ozlabs.org/~rusty/ols-2003-keynote/img53.html

Rusty wins then The point is that strncpy is too easy to misuse.