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

[Joe Mayo]

I think I become more and more alone...
Everybody tells me that C++ is better, because once a project becomes
very large, I should be happy that it has been written in C++ and not C.
I'm the only guy thinking that C is a great programming language and
that there is no need to program things object oriented.

Many people says also that they save more time by programming projects
object oriented, but I think its faster to program them in a good
structured functional way.

What do you think?

--
-= Joe Mayo* =-
* This is a fake name.

[jacob navia]

Richard Heathfield wrote:

jacob navia said:

>H. is arguing that strncmp is not a string comparison function.

Heathfield

That's right.

[snip]

Yes, I agree that it's a comparison function. So what?

OK. I give up.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[santosh]

jacob navia wrote:

Richard Heathfield wrote:

>jacob navia said:

>>H. is arguing that strncmp is not a string comparison function.

Heathfield

>That's right.

[snip]

>Yes, I agree that it's a comparison function. So what?

OK. I give up.

Are you really saying you don't know the difference between a comparison
function and string comparison function?

The crucial difference between strcmp and strncmp is that the former _needs_
it's arguments to be null-terminated strings while the latter doesn't.
There is a crucial difference between an array of characters, (which
needn't, but could be, a string), and a string.

[jacob navia]

santosh wrote:

jacob navia wrote:

>Richard Heathfield wrote:

>>jacob navia said:
H. is arguing that strncmp is not a string comparison function.

Heathfield

>>That's right.

[snip]

>>Yes, I agree that it's a comparison function. So what?

OK. I give up.

Are you really saying you don't know the difference between a comparison
function and string comparison function?

The crucial difference between strcmp and strncmp is that the former _needs_
it's arguments to be null-terminated strings while the latter doesn't.
There is a crucial difference between an array of characters, (which
needn't, but could be, a string), and a string.

Look:

1) The standard names EXPLICITELY strncmp a "comparison functions" in
the section String handling.
2) strncmp starts with the prefix "str"
3) Contrary to memcmp, strncmp will STOP the comparison at a zero byte,
i.e. it has STRING SEMANTICS!

But you go on telling that it is not a string comparison function. Ask
any programmer:

Santosh: Good Morning Sir. I am Santosh and I am
making a poll about string functions. Just a single
question: "Strncmp is a string comparison function or not"?

and see what answers you get.

This is so ridiculous that I just can't believe it. Heathfield can say
anything here and there will be always people that follow his stuff.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

jacob navia said:

<snip>

1) The standard names EXPLICITELY strncmp a "comparison functions" in
the section String handling.

Right. It also lists memcmp in the same paragraph. Does that make memcmp a
string function? Of course not. THEREFORE (as I have already explained at
least twice), being mentioned in <string.his insufficient to qualify a
function as being a "string function".

2) strncmp starts with the prefix "str"

So does strncpy, which is not a string function. THEREFORE, starting with
the prefix "str" is not sufficient to qualify a function as being a
"string function".

3) Contrary to memcmp, strncmp will STOP the comparison at a zero byte,
i.e. it has STRING SEMANTICS!

It is indeed true that *if* you pass a string to strncmp, it will honour
the terminator. Similarly, if you pass a string to printf, it will honour
the terminator. We know that printf is not a string function. Therefore,
honouring the terminator is not sufficient to make a function a "string
function". A string function, surely, is *at the very least* a function
that requires at least one of its inputs to be a string (and even that is
not enough to disqualify printf from being a string function).

This is so ridiculous that I just can't believe it.

You can lead a horse to water, but you can't make it drink.

Heathfield can say
anything here and there will be always people that follow his stuff.

You might want to ask yourself why it is that people are more willing to
believe me than they are to believe you. Think hard about that.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard]

santosh <sa*********@gmail.comwrites:

jacob navia wrote:

>Richard Heathfield wrote:

>>jacob navia said:
H. is arguing that strncmp is not a string comparison function.

Heathfield

>>That's right.

[snip]

>>Yes, I agree that it's a comparison function. So what?

OK. I give up.

Are you really saying you don't know the difference between a comparison
function and string comparison function?

The crucial difference between strcmp and strncmp is that the former _needs_
it's arguments to be null-terminated strings while the latter doesn't.
There is a crucial difference between an array of characters, (which
needn't, but could be, a string), and a string.

This is another example of petty one upsmanship and word twisting. Both
work almost exactly the bloody same. The difference is that ONE of them
specifies the maximum number of characters to compare. Not a huge
difference but potentially a very optimal difference where the first N
characters are the UID of the object in question.

Yes, CLEARLY strmp needs a well formed string and strncmp doesnt.

To accuse someone of not knowing the difference between a comparison
function and a "string comparison" function is, in this case, trite and
petty when one considers that its very obvious that the poster knows
what the functions do.

[Richard]

jacob navia <ja***@nospam.orgwrites:

santosh wrote:

>jacob navia wrote:

>>Richard Heathfield wrote:
jacob navia said:
H. is arguing that strncmp is not a string comparison function.
Heathfield
That's right.
[snip]

Yes, I agree that it's a comparison function. So what?

OK. I give up.

Are you really saying you don't know the difference between a comparison
function and string comparison function?

The crucial difference between strcmp and strncmp is that the former _needs_
it's arguments to be null-terminated strings while the latter doesn't.
There is a crucial difference between an array of characters, (which
needn't, but could be, a string), and a string.

Look:

1) The standard names EXPLICITELY strncmp a "comparison functions" in
the section String handling.
2) strncmp starts with the prefix "str"
3) Contrary to memcmp, strncmp will STOP the comparison at a zero byte,
i.e. it has STRING SEMANTICS!

But you go on telling that it is not a string comparison function. Ask
any programmer:

Santosh: Good Morning Sir. I am Santosh and I am
making a poll about string functions. Just a single
question: "Strncmp is a string comparison function or not"?

and see what answers you get.

This is so ridiculous that I just can't believe it. Heathfield can say
anything here and there will be always people that follow his stuff.

I agree.

From the Linux info page:

"strcmp, strncmp - compare two strings"

Santosh seems to be disappearing into picky jobs worth land quicker than I
feared.

[santosh]

jacob navia wrote:

santosh wrote:

>jacob navia wrote:

>>Richard Heathfield wrote:
jacob navia said:
H. is arguing that strncmp is not a string comparison function.
Heathfield
That's right.
[snip]

Yes, I agree that it's a comparison function. So what?

OK. I give up.

Are you really saying you don't know the difference between a comparison
function and string comparison function?

The crucial difference between strcmp and strncmp is that the former
_needs_ it's arguments to be null-terminated strings while the latter
doesn't. There is a crucial difference between an array of characters,
(which needn't, but could be, a string), and a string.

Look:

1) The standard names EXPLICITELY strncmp a "comparison functions" in
the section String handling.
2) strncmp starts with the prefix "str"
3) Contrary to memcmp, strncmp will STOP the comparison at a zero byte,
i.e. it has STRING SEMANTICS!

Yes, but it doesn't _require_ it's arguments to be strings.

But you go on telling that it is not a string comparison function.

At the very least I'd say it's a sub-string comparison function.

<snip>

[jacob navia]

santosh wrote:

>
At the very least I'd say it's a sub-string comparison function.

YES!

That's why it has the "n" integer argument. At most n chars comparison.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Charlie Gordon]

"Al Balmer" <al******@att.neta écrit dans le message de news:
5f********************************@4ax.com...

On Wed, 3 Oct 2007 10:35:52 +0200, "Charlie Gordon" <ne**@chqrlie.org>
wrote:

>>>It's a shame the committee would not define a proper library function
for
limited string copy and concatenation,

Perhaps - but that is not what strncpy is for.

But so few programmers understand that.

Oh, nonsense. I'm getting tired of this. It seems to me that you
either have experience with a very limited (and incompetent) group of
programmers, or are projecting your own assumptions to the universe.

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.

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

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

--
Chqrlie.

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
LP*********************@bt.com...

Richard Weeks said:

<snip>

>
Here is an example of a *good* use of strncpy (which is otherwise not
terribly well-written, but I've tried to make it as clear as possible):

char date[25] = "";
char *d = asctime(&tmstruct);
strncpy(date, d + 11, 9); /* hh:mm:ss */
strncpy(date + 9, d, 4); /* nnn */
strncpy(date + 9 + 4, d + 8, 3); /* dd */
strncpy(date + 9 + 4 + 3, d + 4, 4); /* mmm */
strncpy(date + 9 + 4 + 3 + 4, d + 20, 4); /* yyyy */

That's what it's for - building a record a piece at a time by copying data
from a record-like (multiple field) source.

And it does that job perfectly well.

Nonsense! The right tool for the job above is memcpy in all cases.
strncpy can be used for that, but is not the right tool, sprintf could have
been used too with better readability and even worse performance.

--
Chqrlie.

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
ap*********************@bt.com...

Tor Rustad said:

>Richard Weeks wrote:

>>Charlie Gordon wrote:

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.
For the edification a programmer (myself) with varying degrees of skill,
what exactly are strncpy's "woes?"

Read this paper:

http://www.gratisoft.us/todd/papers/strlcpy.html

The first mistake I found is in the first sentence: "length-bounded string
functions such as strncpy()". Finding other mistakes is left as an
exercise for the reader.

Finding teachings is a better reason to read this paper.

As far as shortcomings, I personally do not like the API they chose for
strlcpy and strlcat: I would pass the size of the destination array as the
second argument instead of the third.

--
Chqrlie.

[Charlie Gordon]

"Tor Rustad" <to********@hotmail.coma écrit dans le message de news:
m8*********************@telenor.com...
<snip>

>
For the special case you describe, I would rather write something like:

n = sprintf(dest, "%.*s", max, src);

Achtung Minen!

max is not the size of the destination array ``dest'', it should be at most
one less than that, and n will not exceed max, so truncation cannot be
detected. A better approach is this:

n = snprintf(dest, size_of_dest, "%s", src);

if (n >= size_of_dest) {
/* truncation occurred */
}

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: LP*********************@bt.com...

>>
That's what [strncpy is] for - building a record a piece at
a time by copying data from a record-like (multiple field) source.

And it does that job perfectly well.

Nonsense!

I can't agree that it's nonsense.

The right tool for the job above is memcpy in all cases.
strncpy can be used for that, but is not the right tool, sprintf could
have been used too with better readability and even worse performance.

Well, here I'm a bit torn, because I kind of agree with you, insofar as, in
that situation, I would use memcpy. Nevertheless, if I saw strncpy being
used in that way in a code review, I'd let it go. It's no less correct or
readable than the same code with memcpy would be.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Charlie Gordon]

"Tor Rustad" <to********@hotmail.coma écrit dans le message de news:
up*********************@telenor.com...

Al Balmer wrote:

>On Wed, 03 Oct 2007 00:53:55 +0200, Tor Rustad
<to********@hotmail.comwrote:

>>Al Balmer wrote:
On Tue, 02 Oct 2007 22:47:19 +0200, Tor Rustad
<to********@hotmail.comwrote:

....

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

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 don't consider truncation a feature at all, but rather way to implement
run-time recovery.

If destination buffer doesn't have the required size to hold all the data,
it's typically a programming fault, and silencing such a thing, is IMO not
the way solid code should be.

Whether it is a feature or a fault depends on context.
Detecting truncation with strlcpy and strlcat is as easy as detecting
failure from malloc.

if (strlcpy(dest, src, size) >= size) {
/* truncation occurred */
}

Ignoring truncation can be fine for formating informative output on a
limited width terminal, while it would be typically wrong for computing a
file path.

strcpy_s does not implement truncation, it detects overflow and reports it
in various ways. If you want mere truncation, strlcpy is what you need.

--
Chqrlie.

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
bc******************************@bt.com...

Charlie Gordon said:

>"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: LP*********************@bt.com...

>>>
That's what [strncpy is] for - building a record a piece at
a time by copying data from a record-like (multiple field) source.

And it does that job perfectly well.

Nonsense!

I can't agree that it's nonsense.

nonsense applies to "perfectly" and "That's what strncpy is for"

strncpy can be used for that, but that is not what it is for. You do not
need the peculiar semantics of strncpy in your example, you merely swing
around them with adequate arguments and data.
The right tool here *is* memcpy.

>The right tool for the job above is memcpy in all cases.
strncpy can be used for that, but is not the right tool, sprintf could
have been used too with better readability and even worse performance.

Well, here I'm a bit torn, because I kind of agree with you, insofar as,
in
that situation, I would use memcpy. Nevertheless, if I saw strncpy being
used in that way in a code review, I'd let it go. It's no less correct or
readable than the same code with memcpy would be.

But it is less efficient, especially with inline expansion and fixed widths.
strncpy here is just not "le mot juste"

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

<snip>

>
But it is less efficient, especially with inline expansion and fixed
widths. strncpy here is just not "le mot juste"

Whether it is less efficient is not a matter for speculation, but for
measurement.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Tor Rustad]

Flash Gordon wrote:

Tor Rustad wrote, On 04/10/07 01:07:

[...]

>The problem isn't that I can't imagine such a usage, but that this use
case is rather a typical programming *fault*. So, I deliberately put
the assert() in there, to catch it.

For the special case you describe, I would rather write something like:

n = sprintf(dest, "%.*s", max, src);

I would not because you are needlessly calling a more complex function.
I would also consider it to be a micro-*de*optimisation, i.e. using
something that looks like it will be less efficient for no good reason

Well, the database experts hardly need any help, to construct an
effective copy-and-truncate function. My example above, was a quick and
simple C solution, for the rare case I would need such a function
myself, which so far has been... approx *zero* times. :-)

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

"Premature tuning is the root of all evil"

[Tor Rustad]

Al Balmer wrote:

On Wed, 03 Oct 2007 22:14:22 +0200, Tor Rustad
<to********@hotmail.comwrote:

>>? 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 don't consider truncation a feature at all,

Truncation is what it does with overlength sources. That's what it's
for.

I don't know why you make such a big deal out of this, to avoid buffer
overflow, the destination *string*, simply has to get truncated on
over-sized input.

Considering usual programming faults, a feature... that lead to
hard-to-audit code. When performing code audit, I prefer to focus on the
non-trivial cases, rather than wasting energy on some "clever" features.

Then why an assert? What's wrong with just returning the length of the
source, allowing the user to check whether it's longer than the size
copied? As I understand it, that's what the conventional
implementation does.

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.

When operating on *fixed-sized* strings, it is rather artificial to
construct cases, where you like to silence truncations.

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

"Life is full of shit, if you look at it"

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
se*********************@bt.com...

Tor Rustad said:

>Richard Heathfield wrote:

>>Tor Rustad said:

<snip>

>>>http://www.gratisoft.us/todd/papers/strlcpy.html

The first mistake I found is in the first sentence: "length-bounded
string functions such as strncpy()". Finding other mistakes is left as
an exercise for the reader.

Now, you are being childish.

Well, obviously I disagree. Let me explain why.

>It's prototype is in <string.h>,

So are those of memcpy, memmove, memcmp, memchr, and memset, which are not
string functions. So the inclusion of a prototype in <string.his not
sufficient to qualify a function as being a "string function".

>it's name has "str" prefix.

So does strncmp, which is not a string processing function either. So the
prefix str is not sufficient to qualify a function as being a "string
function".

Furthermore, there are several functions that require strings as input but
which do not start "str" - *printf, *scanf, atoi, atod, atol, perror,
fopen, to name but a few. These aren't what we might normally think of as
"string functions", but they do at least require strings as input.

strncpy does *not* require even one string as input. It is therefore
somewhat difficult to see how we can justify calling it a "string
function", despite its (badly-chosen) name.

Since you are nitpicking on every meaningless detail, you should also note
that none of atoi, atod, atol, or strto* require strings as input. As long
as the char array argument contains a delimiter, they are required to
attempt to parse it as a number and stop right after that. The fact the
Standard refers to their argument as a string and insist on splitting it in
3 parts with the latter '\0' terminated should probably be considered a
defect, because it is an unneeded constraint.

The Standard unambiguously refers to all functions defined in <string.has
string functions, notably in 7.21 String handling, 7.21.1 String function
conventions.

--
Chqrlie.

[Malcolm McLean]

"jacob navia" <ja***@nospam.orgwrote in message

Keith Thompson wrote:
[snip]

>The real lesson: assuming that the C standard library is a consistent
and coherently designed interface is dangerous. It isn't. Once you
understand that, you'll probably be ok.

But isn't that acknowledging that this part of the language
needs reworking?

Those _s functions like fopen_s and others proposed in that
Technical Report are a start isn't it?

Kind of. The standard library was designed in the 1970s. Things have moved
on since then, and some decision which seemed sensible at the time we now
know are wrong, or the relaxation of memory and processor constraints has
made them wrong.

However I fail to see what fopen_s adds in terms of safety. It seems to me a
totally pointless change to the interface, workable but made for the purpose
of changing it.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Thu, 04 Oct 2007 23:52:19 +0200, Charlie Gordon wrote:

Since you are nitpicking on every meaningless detail, you should also
note that none of atoi, atod, atol, or strto* require strings as input.

The behaviour is undefined if you do

atoi((char [4]) { "123x" })

As long as the char array argument contains a delimiter, they are
required to attempt to parse it as a number and stop right after that.

They are not. Unless there is specific text saying otherwise, they are
permitted to look for the end of the string, and then scan backwards.
They do not have to do this intelligently. They may crash (or worse) on
non-string arguments.

The fact the Standard refers to their argument as a string and insist on
splitting it in 3 parts with the latter '\0' terminated should probably
be considered a defect, because it is an unneeded constraint.

You ackownledge here that the standard does require a string argument.
You are correct that this is requirement is not necessary, but that
doesn't make it any less of one.

The Standard unambiguously refers to all functions defined in <string.h>
as string functions, notably in 7.21 String handling, 7.21.1 String
function conventions.

It is not unambiguous. 7.21.1 also addresses the typedef size_t and the
macro NULL, neither of which are functions, let alone string functions.

And "notably" suggests there are other less notable references to the
<string.hfunctions as string functions. I cannot find any. Do you have
any other examples?

[Tor Rustad]

Richard Heathfield wrote:

Tor Rustad said:

>Richard Heathfield wrote:

>>Tor Rustad said:

<snip>

>>>http://www.gratisoft.us/todd/papers/strlcpy.html
The first mistake I found is in the first sentence: "length-bounded
string functions such as strncpy()". Finding other mistakes is left as
an exercise for the reader.

Now, you are being childish.

Well, obviously I disagree. Let me explain why.

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

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.

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, not that you
referred to some common practice wording.

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

"Life is full of shit, if you look at it"

[Richard Heathfield]

Tor Rustad said:

<snip>

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 <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Richard Heathfield wrote:

Charlie Gordon said:
<snip>

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

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.

[Al Balmer]

On Thu, 04 Oct 2007 23:40:57 +0200, Tor Rustad
<to********@hotmail.comwrote:

>Then why an assert? What's wrong with just returning the length of the
source, allowing the user to check whether it's longer than the size
copied? As I understand it, that's what the conventional
implementation does.

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
Sun City, AZ

[Al Balmer]

On Thu, 4 Oct 2007 22:33:29 +0200, "Charlie Gordon" <ne**@chqrlie.org>
wrote:

>"Al Balmer" <al******@att.neta écrit dans le message de news:
5f********************************@4ax.com...

>On Wed, 3 Oct 2007 10:35:52 +0200, "Charlie Gordon" <ne**@chqrlie.org>
wrote:

>>>>It's a shame the committee would not define a proper library function
for
limited string copy and concatenation,

Perhaps - but that is not what strncpy is for.

But so few programmers understand that.

Oh, nonsense. I'm getting tired of this. It seems to me that you
either have experience with a very limited (and incompetent) group of
programmers, or are projecting your own assumptions to the universe.

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?

--
Al Balmer
Sun City, AZ

[Chris Thomasson]

Minimalist Interfaces For C:

http://groups.google.com/group/comp....106926ba5db19f

[Malcolm McLean]

"Al Balmer" <al******@att.netwrote in message

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

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Tor Rustad]

Al Balmer wrote:

On Thu, 04 Oct 2007 23:40:57 +0200, Tor Rustad
<to********@hotmail.comwrote:

>>Then why an assert? What's wrong with just returning the length of the
source, allowing the user to check whether it's longer than the size
copied? As I understand it, that's what the conventional
implementation does.

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?

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]

"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de news:
_f*********************@bt.com...

>
"Charlie Gordon" <ne**@chqrlie.orgwrote in message

>>
You are right, it is a matter of statistics. strncpy happens to be
misused a lot, causing various kinds of inefficiencies or downright bugs
that lurk in the dark corners of the code, waiting to bite at the least
agreeable moment.

Just don't use this stinking function, use strlcpy or equivalent instead,
when appropriate.

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.

--
Chqrlie.

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
8_******************************@bt.com...

Tor Rustad said:

<snip>

>alternative for strncpy() and strncat(), was provided by OpenBSD
strlcpy() and strlcat().

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

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

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.

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: 8_******************************@bt.com...

>Tor Rustad said:

<snip>

>>alternative for strncpy() and strncat(), was provided by OpenBSD
strlcpy() and strlcat().

...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 didn't say I had no need for safe or sub-string copy. I said I had no
need for strlcpy() and strlcat().

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Malcolm McLean]

"Charlie Gordon" <ne**@chqrlie.orgwrote in message
news:47***********************@news.free.fr...

"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de
news:

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

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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Flash Gordon]

Malcolm McLean wrote, On 07/10/07 16:28:

>
"Charlie Gordon" <ne**@chqrlie.orgwrote in message
news:47***********************@news.free.fr...

>"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de
news:

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

I've never worked on a database-intensive program.

I do. It's a major part of my job.

However I suspect it has become obsolete.

You are wrong.

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.

Yes, you need to pad with a defined character (space is sometimes used
rather than a null). However the reason is NOT to allow tricks like you
describe above. The reason is so that it can be part of a key (not the
entire key) in such a way as to allow easy sorting and searching without
the datebase itself having to have any understanding of how the key is
constructed.

However nowdays everything would be managed by an sql box and that sort
of consideration is getting out of date.

The incorrect reason you suggested for fixed width fields is dead,
however fixed width fields are very much alive and kicking. Oh, I come
across them a lot in the applications we interface with, not just in our
own applications.

By the way, when I checked last BerkeleyDB had some big customers.

So strncpy() has a declining
niche.

Well, its use has certainly declined since file-systems generally don't
work the same way.
--
Flash Gordon

[spacecriter \(Bill C\)]

Joe Mayo wrote:

I think I become more and more alone...
Everybody tells me that C++ is better, because once a project becomes
very large, I should be happy that it has been written in C++ and not
C. I'm the only guy thinking that C is a great programming language
and that there is no need to program things object oriented.

Many people says also that they save more time by programming projects
object oriented, but I think its faster to program them in a good
structured functional way.

What do you think?

I think that if you use a compiler capable of handling either an OO design
or a structured design, you can do what suits your current application.

I am currently using a C++ compiler to develop a structured design.

I find that the structured style of programming can more readily accomodate
a large number of changes, or a significant paradigm shift found after the
design is complete. I have found that OO designs are harder to change, and,
thus, slower to respond in those situations.

--
Bill C.

[santosh]

spacecriter (Bill C) wrote:

<snip>

I find that the structured style of programming can more readily
accomodate a large number of changes, or a significant paradigm shift
found after the design is complete. I have found that OO designs are
harder to change, and, thus, slower to respond in those situations.

Proponent of OOP will be very interested with this paragraph.

[Charlton Wilbur]

>>>>"s" == santosh <sa*********@gmail.comwrites:

sspacecriter (Bill C) wrote:

>I find that the structured style of programming can more
readily accomodate a large number of changes, or a significant
paradigm shift found after the design is complete. I have
found that OO designs are harder to change, and, thus, slower
to respond in those situations.

sProponent of OOP will be very interested with this paragraph.

Not really: he's speaking of his own experience, and I can't change
what he's experienced; and convincing him that the experience is the
exact opposite for many people is probably a waste of time.

Further, c.l.c is a poor choice of fora for an extended OOP advocacy
flamewar.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net

[spacecriter \(Bill C\)]

Charlton Wilbur wrote:

>>>>>"s" == santosh <sa*********@gmail.comwrites:

sspacecriter (Bill C) wrote:

>I find that the structured style of programming can more
>readily accomodate a large number of changes, or a significant
>paradigm shift found after the design is complete. I have
>found that OO designs are harder to change, and, thus, slower
>to respond in those situations.

sProponent of OOP will be very interested with this paragraph.

Not really: he's speaking of his own experience, and I can't change
what he's experienced; and convincing him that the experience is the
exact opposite for many people is probably a waste of time.

Further, c.l.c is a poor choice of fora for an extended OOP advocacy
flamewar.

Agreed.

I really didn't mean to throw out any flame bait, but after re-reading what
I wrote, I could see how it would be misconstrued in that fashion.

I mearly meant to point out to the OP that I shared his perspetive on
structured programs, and that C++ != OOP.
--
Bill C. "I am NOT lost.... I'm *exploring*"
'01 FXDXT
'94 Shadow VLX
yank "yercrank" to e-mail

[jacob navia]

Charlie Gordon wrote:
[snip]

I know perfectly well what strncpy does and am
quite capable of using it correctly. In my projects, I have never seen a
single place where its semantics were appropriate. strncpy has never been
"the right thing", contrary to strlcpy. My "boring" persistence at warning
other programmers about strncpy is a pedagogical move : so many "savvy"
regulars on c.l.c seem unable to grasp the concept of "error prone" and "too
easy to misuse".

This is exactly the problem. If an interface is consistently misused
this doesn't mean that all programers are stupid but that is BADLY
DESIGNED!

The C library was designed around 30 years ago and this shows!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[David Thompson]

On Fri, 05 Oct 2007 09:58:36 +0200, Joe Mayo <jo******@supermail.tld>
wrote:
<snip>

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.

Compared to C++, the 'big' points that C does not have are: templates;
exceptions; ANY member accessibility (private or protected) and scoped
(aka nested) types and enums; member functions; static members;
namespaces; inheritance, and (related) polymorphism/dispatching;
overloading (operators or functions), and (related) references; and a
bunch of library stuff (which depend on templates and inheritance).
There are also several minor differences even in what appears to be
the 'common subset', which can getcha if you compile C as C++ or C++
as C without looking, but can easily be avoided or fixed.

Using a prefix underscore to simulate private (or anything else) is a
bad idea; in both C and C++ _many_ identifiers beginning with
underscore are reserved to the implementation. There are some you can
use if you are really careful, and also all maintenance programmers
following you, but it's easier and more robust to just avoid them all.

- formerly david.thompson1 || achar(64) || worldnet.att.net