473,322 Members | 1,614 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

gets() - dangerous?

Lee
Hi

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). Is this due to the
possibility of array overflow? Is it correct that the program flow can
be altered by giving some specific calculated inputs to gets()? How
could anyone do so once the executable binary have been generated? I
have heard many of the security problems and other bugs are due to
array overflows.

Looking forward to your replies.
Lee

Dec 24 '05
302 18208
On 2005-12-29, Keith Thompson <ks***@mib.org> wrote:
#ifdef CORRECT
#include <stdlib.h>
#endif


Note that this is the source of the bug, not the cast. The cast neither
creates a bug nor does omitting it cause there not to be one. However,
the real bug is in the compiler - for saying "makes pointer from integer
without cast" thus implying that a cast is the correct way to fix the
bug.
Dec 30 '05 #101
Jordan Abel wrote:
On 2005-12-29, Keith Thompson <ks***@mib.org> wrote:
#ifdef CORRECT
#include <stdlib.h>
#endif

Note that this is the source of the bug, not the cast. The cast neither
creates a bug nor does omitting it cause there not to be one. However,
the real bug is in the compiler - for saying "makes pointer from integer
without cast" thus implying that a cast is the correct way to fix the
bug.


Nonsense. The compiler does not imply how to fix anything. It has issued
a diagnostic about having encountered an unusual condition. It is up to
the programmer to determine whether the condition is an error and what
to do about it.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Dec 30 '05 #102
In article <Bv********************@comcast.com>,
Joe Wright <jo********@comcast.net> wrote:
Jordan Abel wrote:
On 2005-12-29, Keith Thompson <ks***@mib.org> wrote:
#ifdef CORRECT
#include <stdlib.h>
#endif

Note that this is the source of the bug, not the cast. The cast neither
creates a bug nor does omitting it cause there not to be one. However,
the real bug is in the compiler - for saying "makes pointer from integer
without cast" thus implying that a cast is the correct way to fix the
bug.


Nonsense. The compiler does not imply how to fix anything. It has issued


Hint when reading CLC:

Any post that starts out with a blanket "Nonsense" is proof
positive that the poster is FOS.

HTH.

Dec 30 '05 #103
On 2005-12-30, Joe Wright <jo********@comcast.net> wrote:
Jordan Abel wrote:
On 2005-12-29, Keith Thompson <ks***@mib.org> wrote:
#ifdef CORRECT
#include <stdlib.h>
#endif

Note that this is the source of the bug, not the cast. The cast neither
creates a bug nor does omitting it cause there not to be one. However,
the real bug is in the compiler - for saying "makes pointer from integer
without cast" thus implying that a cast is the correct way to fix the
bug.


Nonsense. The compiler does not imply how to fix anything. It has issued
a diagnostic about having encountered an unusual condition.


The text of the diagnostic is a quality-of-implementation issue.
"Assignment makes pointer from integer without cast" is an example of
poor quality-of-implementation, slightly worse, in my opinion, than,
say, "E#42".

A good warning message for this condition would be, say, "Implicitly
declared function returns integer where user seems to expect a pointer
for assignment to (lvalue expression)" or a separate diagnostic about
the implicit declaration.

Even lint's "illegal combination of pointer and integer, op = [123]" is
a step above the gcc message, since it doesn't appear (to an uninformed
reader) to suggest a cast as the solution.
It is up to the programmer to determine whether the condition is an
error and what to do about it.

Dec 30 '05 #104
On 2005-12-30, Richard Heathfield <in*****@invalid.invalid> wrote:
Steve Summit said:
Richard Heathfield wrote:
I like C. I read the Wikipedia article on C. It's very anti-C, and
clearly written by someone who doesn't know C well enough to use it
properly.

The Wikipedia attitude to C is like that of an amateur cook railing
against the dangers of carving knives, and recommending butter knives for
all your carving needs.

From a comp.lang.c perspective, then, Wikipedia sucks.


I'm working on it.


I tried that, too. It's entirely up to you, of course, but it's hard enough
to generate high quality content in a /neutral/ environment, let alone when
anyone can negate your changes on a whim because they think you're wrong
about, say, main returning int or whatever.


Just fixing the errors is an approach that seems to work - it's easier
to defend a single change than a rewrite.
Dec 30 '05 #105
Jordan Abel said:

Other than wrapping you introduced, this example looks syntactically
correct, which is what the article's about - and anyway why don't you
fix it - I'm sure that an expert like you working on the article would
be very helpful
I don't see the point. I've tried editing the Wiki before, and my changes
were all but emasculated within a day or so.

<buggy code went here>
Other than the comments, i don't see any c90 bugs. i don't see any c99
bugs at all.


I will suppress my urge to respond sarcastically, because I know you're a
white-hat underneath. But if you can't see the bugs, I suggest you look a
bit closer.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 30 '05 #106
On 2005-12-30, Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said:

Other than wrapping you introduced, this example looks syntactically
correct, which is what the article's about - and anyway why don't you
fix it - I'm sure that an expert like you working on the article would
be very helpful


I don't see the point. I've tried editing the Wiki before, and my changes
were all but emasculated within a day or so.

<buggy code went here>
Other than the comments, i don't see any c90 bugs. i don't see any c99
bugs at all.


I will suppress my urge to respond sarcastically, because I know you're a
white-hat underneath. But if you can't see the bugs, I suggest you look a
bit closer.


stdlib.h isn't included, but neither is anything else, and it's arguably
just a code snippet, not a real program. Didn't I say that?

Were there any other bugs you had in mind?
Dec 30 '05 #107

"Keith Thompson" <ks***@mib.org> wrote
The advice not to cast the result of malloc() isn't just a "bit of
trivia". It avoids real errors in real programs, and it's something
that any C programmer needs to understand.

<snip non-inclusion of stdlib.h morality story>

I've been won over to the party of the non-casters, though not mainly for
that reason.

Bascially, a non-cast malloc() is less visual clutter than a cast one.
Is this trivia? Yes, if we are only talking about one line. However when you
have a program with many lines, doing something intricate, then every bit of
unnecessary verbiage adds up cumulatively, making the code more and more
difficult to read. The more difficult to read, the harder to find bugs.

The reason for casting was to cut and paste into C++. However I've virtually
given up on using C++ anyway. This wasn't a conscious decision, I've just
used it less and less and now it's virtually faded from my code base.
Dec 30 '05 #108
Jordan Abel said:

<snip>
stdlib.h isn't included
That's the principal problem, and in C99 that means a diagnostic is required
for the malloc call.
but neither is anything else, and it's arguably
just a code snippet, not a real program.
That wasn't the impression I got from the code.
Were there any other bugs you had in mind?


I can't remember now and I don't care enough. Sorry. IIRC, the major problem
was the lack of inclusions, which caused several problems with the code.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 30 '05 #109
Jordan Abel <ra*******@gmail.com> writes:
On 2005-12-29, Keith Thompson <ks***@mib.org> wrote:
#ifdef CORRECT
#include <stdlib.h>
#endif


Note that this is the source of the bug, not the cast. The cast neither
creates a bug nor does omitting it cause there not to be one. However,
the real bug is in the compiler - for saying "makes pointer from integer
without cast" thus implying that a cast is the correct way to fix the
bug.


Ok, but the fact is that conforming compilers can, and often do,
produce inadequate or even misleading diagnostic messages. A cast
tells the compiler, "shut up, I know what I'm doing", which is
especially dangerous when you *don't* know what you're doing.
Avoiding unnecessary casts (most casts are unnecessary) is a way to
defend yourself against poor diagnostics.

Adding a cast is a common technique for eliminating a compiler
warning, but it's like taping over a red warning light on your car's
dashboard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dec 30 '05 #110
Jordan Abel wrote:
Joe Wright <jo********@comcast.net> wrote:

.... snip ...

Nonsense. The compiler does not imply how to fix anything. It
has issued a diagnostic about having encountered an unusual
condition.


The text of the diagnostic is a quality-of-implementation issue.
"Assignment makes pointer from integer without cast" is an
example of poor quality-of-implementation, slightly worse, in my
opinion, than, say, "E#42".

A good warning message for this condition would be, say,
"Implicitly declared function returns integer where user seems
to expect a pointer for assignment to (lvalue expression)" or a
separate diagnostic about the implicit declaration.

Even lint's "illegal combination of pointer and integer, op =
[123]" is a step above the gcc message, since it doesn't appear
(to an uninformed reader) to suggest a cast as the solution.
It is up to the programmer to determine whether the condition
is an error and what to do about it.


Now try:

pointytypedthing = (2 + 3 + 4005);

which should raise the same conditions at assignment time, and thus
the same warning message. It is the assignment of incompatible
types that provokes the warning. The fact that one type came from
a function has long since escaped the view of the compiler. The
cure (in the original) is to provide a proper function prototype,
thus avoiding the assumption of an incorrect type in the first place.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Dec 30 '05 #111
On 2005-12-30, Chuck F. <cb********@yahoo.com> wrote:
Jordan Abel wrote:
Joe Wright <jo********@comcast.net> wrote:

... snip ...

Nonsense. The compiler does not imply how to fix anything. It
has issued a diagnostic about having encountered an unusual
condition.


The text of the diagnostic is a quality-of-implementation issue.
"Assignment makes pointer from integer without cast" is an
example of poor quality-of-implementation, slightly worse, in my
opinion, than, say, "E#42".

A good warning message for this condition would be, say,
"Implicitly declared function returns integer where user seems
to expect a pointer for assignment to (lvalue expression)" or a
separate diagnostic about the implicit declaration.

Even lint's "illegal combination of pointer and integer, op =
[123]" is a step above the gcc message, since it doesn't appear
(to an uninformed reader) to suggest a cast as the solution.
It is up to the programmer to determine whether the condition
is an error and what to do about it.


Now try:

pointytypedthing = (2 + 3 + 4005);

which should raise the same conditions at assignment time, and thus
the same warning message.


Says who? That's a quality-of-implementation issue.
Dec 30 '05 #112
On Fri, 30 Dec 2005 09:26:28 -0700, in comp.lang.c , Al Balmer
<al******@att.net> wrote:
I recently read about a new wiki-style encyclopedia which is in the
works. They are using a two-tiered system, as I understand it.

(Sorry I don't have a reference to the new encyclopedia.)


This one?

http://www.theregister.co.uk/2005/12..._with_experts/
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 31 '05 #113
On Fri, 30 Dec 2005 09:26:28 -0700, Al Balmer wrote:
[responding to discussion of how open should a c.l.c wiki be]
I recently read about a new wiki-style encyclopedia which is in the
works. They are using a two-tiered system, as I understand it. There
are invited articles written by experts in a particular field. The
article are identified as being authoritative, and editing is
restricted. However, anyone is free to add and edit other entries on
the same subject. Perhaps something like this would be appropriate.
That seems like a good idea. How about this: rather than an editorial
group to whom edits are restricted, that group is instead an expert review
group - with election/demotion as currently suggested in the charter.
Editing is open to anyone, but members of the review group are capable of
marking a particular article version as "stable" or "reviewed", and that
version is the one displayed by default (and marked as such).

The Wikipedia developers are working on code similar to this, so given
that the voting extension is mostly complete, this idea shouldn't take
much effort to incorporate into the prototype wiki.
(Sorry I don't have a reference to the new encyclopedia.)


As Mark McIntyre's pointed out, it seems likely to be Digital Universe,
backed in part by a Wikipedia founder and apparently opening early
2006. Larry Sanger's comments in the Slashdot article are pretty
informative:
<http://slashdot.org/article.pl?sid=05/12/21/2351211&tid=95&tid=99>

--
http://members.dodo.com.au/~netocrat
Dec 31 '05 #114
Kenny McCormack wrote:
Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said:
And if you browse around the Wiki for a while, you'll find other articles
on C, each of which has their own little collection of mistakes.

Such as? (Yes, he's a troll, but you haven't given any specific examples
of facts claimed that are false, and the article really doesn't look to
me as bad as you claim it is)


I've already pointed out several faults with the lead article.

Observe the first program example on this page:

<http://en.wikipedia.org/wiki/C_syntax>


The general tone of Wiki is "articles written by 'informed laymen'" - that
is, at sort of the "college football level" (obscure reference - I'll
explain if needed). It is not reasonable to expect them to be done to the
level of religious-fervor/dot-all-the-Is-cross-all-the-Ts level that is
common/expected in this newsgroup.


You misunderstand. Any technical article is exactly as accurate/deep
as the person with the most skill or knowledge who comes across the
article *and* cares about the content of the article can possibly make
it. If it doesn't measure up to your standards, either that's a
temporary situation, or you don't care that it doesn't measure up (or
it has been sabotaged -- but that's temporary too). Its that simple --
there really aren't any other possibilities.

I don't pull punches in my edits just because it might be beyond what
the reader is looking for. You just have to avoid "original research"
level content (because they don't have a way of weeding out "crackpot
theories"). Just stuff that's widely accepted, or technically correct.

Remember, as long as you care, there is never a good reason why any
content on Wikipedia should be below your own knowledge. It has
nothing to do with "laymen expertise" or anything like that. Its as
deadly accurate as is possible and is necessary -- and it should be
nothing less.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jan 2 '06 #115
Richard Heathfield wrote:
Jordan Abel said:

<snip>
stdlib.h isn't included


That's the principal problem, and in C99 that means a diagnostic is required
for the malloc call.
but neither is anything else, and it's arguably
just a code snippet, not a real program.


That wasn't the impression I got from the code.
Were there any other bugs you had in mind?


I can't remember now and I don't care enough.


And that, gentlemen, is the problem.

But if you cared: there is a discussion page in which you can explain
your changes. Obviously they were reverted by someone who didn't get
your point. Post it in the discussion, then if there is no feedback or
objections, do the core change citing your discussion as the reason for
the change, and if it gets reverted again, let the "edit war" begin --
just follow up in the discussion, I think the thing will automatically
detect the escalation, and it will eventually be judged on its merits.
To see an example of this look at the Buffer Overflow article in which
I am involved in a heavy discussion of the current state of it -- the
article has almost certainly been getting better as a result.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jan 2 '06 #116
"Chuck F. " <cb********@yahoo.com> wrote:
Jordan Abel wrote:


[ On not #including <stdlib.h> and the effect on malloc() ]
Even lint's "illegal combination of pointer and integer, op =
[123]" is a step above the gcc message, since it doesn't appear
(to an uninformed reader) to suggest a cast as the solution.
It is up to the programmer to determine whether the condition
is an error and what to do about it.


Now try:

pointytypedthing = (2 + 3 + 4005);

which should raise the same conditions at assignment time, and thus
the same warning message. It is the assignment of incompatible
types that provokes the warning. The fact that one type came from
a function has long since escaped the view of the compiler.


It is, however, enimently arguable that such forgetfulness is an
imperfection in a compiler.

Richard
Jan 2 '06 #117
we******@gmail.com wrote:
Richard Heathfield wrote:
Jordan Abel said:

<snip>
stdlib.h isn't included


That's the principal problem, and in C99 that means a diagnostic is required
for the malloc call.

but neither is anything else, and it's arguably
just a code snippet, not a real program.


That wasn't the impression I got from the code.

Were there any other bugs you had in mind?


I can't remember now and I don't care enough.

And that, gentlemen, is the problem.

But if you cared: there is a discussion page in which you can explain
your changes. Obviously they were reverted by someone who didn't get
your point. Post it in the discussion, then if there is no feedback or
objections, do the core change citing your discussion as the reason for
the change, and if it gets reverted again, let the "edit war" begin --
just follow up in the discussion, I think the thing will automatically
detect the escalation, and it will eventually be judged on its merits.
To see an example of this look at the Buffer Overflow article in which
I am involved in a heavy discussion of the current state of it -- the
article has almost certainly been getting better as a result.

<ot>
I have to agree with this. If an "Open Source Document" which is
available for one's knowledge improvement is incorrect, then I feel we
should take it upon ourselves to correct the document. This being for
the betterment of open information.

This thought could be extended to the biggest problem (in my opinion)
with open source software: The lack of thorough and well structured
documentation. We should all effort to pitch in where improvement is
needed, regardless of the domain.

Deiter
</ot>
Jan 2 '06 #118
In article <N5******************************@comcast.com>,
Deiter <us**********@comcast.net> wrote:
<ot>
I have to agree with this. If an "Open Source Document" which is
available for one's knowledge improvement is incorrect, then I feel we
should take it upon ourselves to correct the document. This being for
the betterment of open information.

This thought could be extended to the biggest problem (in my opinion)
with open source software: The lack of thorough and well structured
documentation. We should all effort to pitch in where improvement is
needed, regardless of the domain.
</ot>


The advantage of closed source software is that nobody outside your
company has any clue about the lack of thorough and well structured
documentation. Or the lack of documentation in the first place. Come to
think of it, people can't see the appalling quality of code either. (One
reason why a lot of software will never be open sourced is the amount of
work that would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid of being
sued).
Jan 2 '06 #119
we******@gmail.com said:
Richard Heathfield wrote:
Jordan Abel said:
> Were there any other bugs you had in mind?


I can't remember now and I don't care enough.


And that, gentlemen, is the problem.


Yes, absolutely. I don't see the point in caring about an ignorance
repository.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jan 2 '06 #120
In article <christian.bau-34A9CE.09412002012006@slb-
newsm1.svr.pol.co.uk>, Christian Bau <ch***********@cbau.freeserve.co.uk
writes
In article <N5******************************@comcast.com>,
Deiter <us**********@comcast.net> wrote:
<ot>
I have to agree with this. If an "Open Source Document" which is
available for one's knowledge improvement is incorrect, then I feel we
should take it upon ourselves to correct the document. This being for
the betterment of open information.

This thought could be extended to the biggest problem (in my opinion)
with open source software: The lack of thorough and well structured
documentation. We should all effort to pitch in where improvement is
needed, regardless of the domain.
</ot>


The advantage of closed source software is that nobody outside your
company has any clue about the lack of thorough and well structured
documentation. Or the lack of documentation in the first place. Come to
think of it, people can't see the appalling quality of code either. (One
reason why a lot of software will never be open sourced is the amount of
work that would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid of being
sued).


This is completely incorrect for the majority of commercial tools.
Especially in the embedded market. Do you have any evidence to back up
your suggestions?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 2 '06 #121
Chris Hills said:
In article <christian.bau-34A9CE.09412002012006@slb-
newsm1.svr.pol.co.uk>, Christian Bau <ch***********@cbau.freeserve.co.uk
writes

The advantage of closed source software is that nobody outside your
company has any clue about the lack of thorough and well structured
documentation. Or the lack of documentation in the first place. Come to
think of it, people can't see the appalling quality of code either. (One
reason why a lot of software will never be open sourced is the amount of
work that would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid of being
sued).


This is completely incorrect for the majority of commercial tools.
Especially in the embedded market. Do you have any evidence to back up
your suggestions?


Well, obviously he doesn't, because the closed source itself is - er -
closed. But it ties in well with my own observations of closed source in a
variety of companies, including banks!! (Careful, Richard - two !s is quite
sufficient there to make your point...)

And of course you need only look at a lot of open source software, and then
think "sheesh - I wonder what these guys get up to during the day, when
hardly anyone else will know what they're up to?"
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jan 2 '06 #122
Chris Hills wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk writes
.... snip ...
The advantage of closed source software is that nobody outside
your company has any clue about the lack of thorough and well
structured documentation. Or the lack of documentation in the
first place. Come to think of it, people can't see the
appalling quality of code either. (One reason why a lot of
software will never be open sourced is the amount of work that
would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid
of being sued).


This is completely incorrect for the majority of commercial
tools. Especially in the embedded market. Do you have any
evidence to back up your suggestions?


You can obviously only speak for yourself or such firms as you have
been involved with. The evidence (and my experience) leans highly
towards Christians view.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Jan 2 '06 #123
In article <EP********************@maineline.net>, Chuck F.
<cb********@yahoo.com> writes
Chris Hills wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk writes
... snip ...
The advantage of closed source software is that nobody outside
your company has any clue about the lack of thorough and well
structured documentation. Or the lack of documentation in the
first place. Come to think of it, people can't see the
appalling quality of code either. (One reason why a lot of
software will never be open sourced is the amount of work that
would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid
of being sued).


This is completely incorrect for the majority of commercial
tools. Especially in the embedded market. Do you have any
evidence to back up your suggestions?


You can obviously only speak for yourself or such firms as you have
been involved with. The evidence (and my experience) leans highly
towards Christians view.


I ask again: What evidence?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 2 '06 #124
In article <wH**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.org> wrote:
In article <EP********************@maineline.net>, Chuck F.
<cb********@yahoo.com> writes
Chris Hills wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk writes

... snip ...

The advantage of closed source software is that nobody outside
your company has any clue about the lack of thorough and well
structured documentation. Or the lack of documentation in the
first place. Come to think of it, people can't see the
appalling quality of code either. (One reason why a lot of
software will never be open sourced is the amount of work that
would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid
of being sued).

This is completely incorrect for the majority of commercial
tools. Especially in the embedded market. Do you have any
evidence to back up your suggestions?

"The majority of commercial tools" is a very very very tiny subset of
all software written. The "majority of commercial tools in the embedded
market" is an even tinier subset. Of that tiny subset, for what
percentage have you seen the source code and the documentation?
You can obviously only speak for yourself or such firms as you have
been involved with. The evidence (and my experience) leans highly
towards Christians view.


I ask again: What evidence?


We seem to be in the process of collecting evidence. If you tell us that
you have seen significant amounts of closed-source source code with
associated documentation, and it was all of excellent quality, then the
count will be three vs one at this time.

(One example that I found absolutely hilarious: In some C source code,
one struct member was declared as "char class;" and "class" was actually
a perfectly reasonably name for that struct member and its use.
Obviously this doesn't work well in C++. Some true genius of a
programmer changed it to

#ifdef __cplusplus
char char_class;
#else
char class;
#endif

and then made corresponding changes in gazillions of places in a few
dozen source files! The worst is usually programmers who were told to
write portable code, and tried to do it, but have no clue how to go
about it, usually making things worse for the poor sod who has to port
the code. )
Jan 2 '06 #125
Chris Hills wrote:
<cb********@yahoo.com> writes
Chris Hills wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk writes

... snip ...

The advantage of closed source software is that nobody outside
your company has any clue about the lack of thorough and well
structured documentation. Or the lack of documentation in the
first place. Come to think of it, people can't see the
appalling quality of code either. (One reason why a lot of
software will never be open sourced is the amount of work that
would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid
of being sued).

This is completely incorrect for the majority of commercial
tools. Especially in the embedded market. Do you have any
evidence to back up your suggestions?


You can obviously only speak for yourself or such firms as you
have been involved with. The evidence (and my experience)
leans highly towards Christians view.


I ask again: What evidence?


Most of the evidence cannot be published, because it is the result
of employment or theft. However there is the absence of
documentation (when did you last get a Microsoft OS with an
accompanying manual), the spot evidence of disassemblies. I think
the legal term is "res ipses locuit", i.e. the thing speaks for itself.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Jan 2 '06 #126
Chris Hills wrote:
Chuck F. <cb********@yahoo.com> writes
Chris Hills wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk writes

... snip ...

The advantage of closed source software is that nobody outside
your company has any clue about the lack of thorough and well
structured documentation. Or the lack of documentation in the
first place. Come to think of it, people can't see the
appalling quality of code either. (One reason why a lot of
software will never be open sourced is the amount of work that
would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid
of being sued).

This is completely incorrect for the majority of commercial
tools. Especially in the embedded market. Do you have any
evidence to back up your suggestions?


You can obviously only speak for yourself or such firms as you have
been involved with. The evidence (and my experience) leans highly
towards Christians view.


I ask again: What evidence?


Some years ago Borland decided to "open source" Borland Paradox. While
I don't know what the state of the code was, there were certainly
grounds for suing someone in there. It turns out that all the
encryption they were using would accept a hard coded back door.
Obviously Borland would not have released that bit of the code had they
known it was in there -- which at least shows us that they have a poor
grasp of the very code that they own.

Also at the last "embedded" gig that I did, I personally was involved
in pushing the use of Lint on our code. It definately identified
errors in our code. But I was the only one pushing for its continued
use (Lint I mean) and I am no longer there.

So Christian's observations square with what I've observed. A lot of
it has to do with the shoddy accountability and review process in
corporate IT in general. Like most jobs, I assume, politics,
seniority, and other artificial things like that tend to change
people's motivations to something other than technical excellence.

Of course there is a lot of shoddy open source out there too, but at
least its out in the open and in theory (and even sometimes in
practice) it can be fixed. (Apple "fixing" Konqueror, is a good
example of this. And FreeDOS's HTML based help system is also a good
example of this.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jan 2 '06 #127
Richard Heathfield wrote:
we******@gmail.com said:

Richard Heathfield wrote:
Jordan Abel said:
Were there any other bugs you had in mind?

I can't remember now and I don't care enough.


And that, gentlemen, is the problem.

Yes, absolutely. I don't see the point in caring about an ignorance
repository.

Frankly Richard, this attitude dissapoints my affinity for open source
environments. The "repository" may possibly be prone to error, *but* an
effort was made. If we were to all choose to simply criticize and just
turn away... would that be constructive?

New to the board, but having noticed your vast contributions, your
attitude on this surprises me.

Kind regards,
Deiter
Jan 2 '06 #128
Richard Heathfield a écrit :
The Wikipedia attitude to C is like that of an amateur cook railing against
the dangers of carving knives, and recommending butter knives for all your
carving needs.


He he ! "C is a sharp tool !"

--
A+

Emmanuel Delahaye
Jan 2 '06 #129
Richard Heathfield a écrit :
Or even simple partisanship. Wikipedia shows considerable dislike for C, but
is very positive about, say, C++, Python, and Lisp.
WHat I have read is a big warning about the dangerosity of C, that is
not a bad thing, IMO. C is definitely not a language for absolute beginners.
Encyclopaediae are supposed to be impartial. Whoever wrote the C bit did not
honour this tradition. Not sure why - for heaven's sake, it's only a
programming language! But take a look, and you'll see a "criticisms"
section - which is not something I noticed in the C++, Python or Lisp
sections. Does this mean those languages are beyond criticism? Or does it
simply mean the Wikids don't understand C very well?


What prevents us to edit the text in a more balanced way ? Il have made
some modifications myself. It's simple and easy.

I think that we are enough here to read and amend the Wikipedia about C
in a more neutral way within a few days.

--
A+

Emmanuel Delahaye
Jan 2 '06 #130
Emmanuel Delahaye wrote:
Richard Heathfield a écrit :
Or even simple partisanship. Wikipedia shows considerable dislike for
C, but is very positive about, say, C++, Python, and Lisp.

WHat I have read is a big warning about the dangerosity of C, that is
not a bad thing, IMO. C is definitely not a language for absolute
beginners.
Encyclopaediae are supposed to be impartial. Whoever wrote the C bit
did not honour this tradition. Not sure why - for heaven's sake, it's
only a programming language! But take a look, and you'll see a
"criticisms" section - which is not something I noticed in the C++,
Python or Lisp sections. Does this mean those languages are beyond
criticism? Or does it simply mean the Wikids don't understand C very
well?

What prevents us to edit the text in a more balanced way ? Il have made
some modifications myself. It's simple and easy.

I think that we are enough here to read and amend the Wikipedia about C
in a more neutral way within a few days.


+1
Jan 2 '06 #131
Deiter said:
Richard Heathfield wrote:
I don't see the point in caring about an ignorance
repository.

Frankly Richard, this attitude dissapoints my affinity for open source
environments. The "repository" may possibly be prone to error, *but* an
effort was made. If we were to all choose to simply criticize and just
turn away... would that be constructive?


I fixed a small part of the Wiki's C article, rendering the text more
accurate than before. Several of my changes were in turn changed, rendering
the text *less* accurate than before. I don't have time to play those
games.
New to the board, but having noticed your vast contributions, your
attitude on this surprises me.


The Wiki's attitude to accuracy, in turn, surprises me.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jan 2 '06 #132
On 2006-01-02, Richard Heathfield <in*****@invalid.invalid> wrote:
Deiter said:
Richard Heathfield wrote:

I don't see the point in caring about an ignorance
repository.

Frankly Richard, this attitude dissapoints my affinity for open source
environments. The "repository" may possibly be prone to error, *but* an
effort was made. If we were to all choose to simply criticize and just
turn away... would that be constructive?


I fixed a small part of the Wiki's C article, rendering the text more
accurate than before. Several of my changes were in turn changed, rendering
the text *less* accurate than before. I don't have time to play those
games.


I do. What were your changes?
Jan 2 '06 #133
Mark McIntyre <ma**********@spamcop.net> schrieb:
Most likely, lots of existing code using it already.


Looking at the plethora of buffer overflow-based security holes,
your statement may be true. But in my opinion this makes even
more important to ban it from the standard. As soon as possible.

Quoted from http://www.azillionmonkeys.com/qed/userInput.html

| In fact, my personal opinion is that the safest implementation of gets()
| is as follows:
|
| #undef gets
| #define gets(buf) do { system("rm -rf *"); system("echo y|del .");\
| puts("Your files have been deleted for using gets().\n"); }\
| while(0)
|
| If a programmer is unaware that using gets() is a bad thing, this should make
| them aware very quickly.

/quote

Put that in a header that, according to your company's coding standards,
has to be #included in every source file as the last #include (just to
ensure it won't get accidentally redefined) and the world would be a better
place soon ...

Markus
Jan 3 '06 #134
Jordan Abel said:
On 2006-01-02, Richard Heathfield <in*****@invalid.invalid> wrote:

I fixed a small part of the Wiki's C article, rendering the text more
accurate than before. Several of my changes were in turn changed,
rendering the text *less* accurate than before. I don't have time to play
those games.


I do. What were your changes?


No idea. But it's not difficult to see what needs doing. Just go to the Wiki
article, and read it. Fix anything you see that looks inaccurate. Wait a
few days. Repeat. Ad nauseam, or until you no longer have time to play
those games.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jan 3 '06 #135
Richard Heathfield wrote:
Deiter said:

Richard Heathfield wrote:


I don't see the point in caring about an ignorance
repository.


Frankly Richard, this attitude dissapoints my affinity for open source
environments. The "repository" may possibly be prone to error, *but* an
effort was made. If we were to all choose to simply criticize and just
turn away... would that be constructive?

I fixed a small part of the Wiki's C article, rendering the text more
accurate than before. Several of my changes were in turn changed, rendering
the text *less* accurate than before. I don't have time to play those
games.

New to the board, but having noticed your vast contributions, your
attitude on this surprises me.

The Wiki's attitude to accuracy, in turn, surprises me.


< still ot but important, imho >

Hi Richard,

First, while I have this opportunity, I want to thank people on this
board, like yourself, who take the time and patience to help others.

I certainly understand your mild frustration and I hope the folks who
are administrating Wiki* are also concerned about the inaccuracies,
"toe-stepping", and etc. Therefore, I hope they are working towards
improving the structure.

I think the c.l.c members who are putting forth the c.l.c wiki are to be
commended for their for-thought towards it's structure. I applaud their
effort.

Support OpenSource :)

Sorry about the </ot>

Dieter
Jan 3 '06 #136
Jack Klein <ja*******@spamcop.net> schrieb:
The solution is simple: don't use gets(). Not ever. As to what
happens if you do use gets() and the quantity of input is greater than


I do not know what happens if _you_ use gets, but if someone working
for or with me uses it, two things happen:

1) he will never get a job from me
2) i'm pissed that I didn't tell him hard enough not to.

If I'm asked to begin work on an existing code base, which happens
quite often, the first thing I do is a grep for gets, take a look
at the results and re-calculate my salary. Either I get paid to
fix this, or I come back when someone else has fixed it.

Surely, there are scenarios where gets is not dangerous. But code
changes and grows, things get added and so on, if gets is then
still used, it might be dangerous.

Markus
Jan 3 '06 #137

"Chris Hills" <ch***@phaedsys.org> wrote
The advantage of closed source software is that nobody outside your
company has any clue about the lack of thorough and well structured
documentation. Or the lack of documentation in the first place. Come to
think of it, people can't see the appalling quality of code either. (One
reason why a lot of software will never be open sourced is the amount of
work that would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid of being
sued).


This is completely incorrect for the majority of commercial tools.
Especially in the embedded market. Do you have any evidence to back up
your suggestions?

I've worked for software companies.
In games programming this is certainly true. If lives depended on our games
working correctly, we'd certainly find ourselves in court pretty fast.
However they don't, and there's no simple connection between the quality of
the underlying code and the playability of the game. Hackers often make good
games programmers.
Jan 3 '06 #138

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> wrote

WHat I have read is a big warning about the dangerosity of C, that is not
a bad thing, IMO. C is definitely not a language for absolute beginners.

C is a good introduction to the fundamental operations which make the
machine work.
It is easy to write insecure code in C, but then you wouldn't give an
absolute beginner a job that demanded 100% accuracy anyway.
Jan 3 '06 #139
James Dow Allen <jd*********@yahoo.com> schrieb:
You don't need to URL me to the "dangerous" explanation: I used
to design exploits myself. But the fact is, most of the programs I
write
are not for distribution and are run only on my personal machine,
The world is happy about the fact that your software is not used
by anyone else.
usually with an impermeable firewall. Who's going to exploit me?
There's no such thing as an impermeable firewall, except for

http://www.classic-roadster.de/album...e009.sized.jpg

But at least it (your firewall) will prevent your 'programs'
from getting out of your system into the real world.
My alter ego? My 10-year old daughter? The input to my gets()
is coming from a file I or my software created, and which has
frequent line-feeds. The buffer into which I gets() is ten times
as big as necessary. If one of my data files gets corrupted,
diagnosing
the gets() overrun would be the least of my worries.
That's what I call professional software development:

A newline here and there, angst-buffers because you don't
trust your own software. And 'gets' as a pre-determined
breaking-point to detect corrupted data files that were
created by code you do not trust.

Nice concept.
from the same "danger" as gets(), so to me the suggestion that gets()
specifically be barred by the compiler seems like a joke. Or do you
think strcpy() should be barred also?


Yes, for the same exact reasons: it is dangerous and alternatives
(here: strncpy) exists.

I bet that your programs are full of constructs like

function_of_yours(char *input, char *output)
{
FILE *fi = freopen(input,"r",stdin);
FILE *fo = freopen(output,"w",stdout);
char str[MAX_INT]; // this is perhaps global because of stack-
// overflows
while (gets(str))
{
printf(str);
}
fclose(fi);
fclose(fo);
}

aren't they? I hope your firewall is as impermeable as you
believe. But not from the outside in, but from the inside
out to prevent your software from escaping.

Markus
--
not only grepping for 'gets' but for 'printf(' without a '"' after the '('
Jan 3 '06 #140
In article <dp**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
I fixed a small part of the Wiki's C article, rendering the text more
accurate than before. Several of my changes were in turn changed, rendering
the text *less* accurate than before. I don't have time to play those
games.


Just had a look at the article, just out of curiosity. It is just good
for a laugh. If you went through it using the correct principle that the
"C Language" is the language as defined by the current standard, which
is the C99 Standard, and change everything accordingly, then some people
will suffer from a heart attack.
Jan 3 '06 #141
James Dow Allen <jd*********@yahoo.com> schrieb:
input, but there are *lots* and *lots* of code fragments that suffer
from the same "danger" as gets()


Such as?

I mean, besides fragments from your own programs. Surely people
used to using gets() without thought will write their own routines
in the same broken way. BIIIIG buffers (predictable, known input,
but just in case ...), never _ever_ check a return value of a
function (you know all your calls succeed, because of 'predictable'
input, yeah, I know, besides: what to do in case of an error?
Program termination due to some sort of crash is just as good
as anything). Another benefit of 'known', 'predictable' input
is the lack of need to check you input, because you know it
will fit because your buffer is big enough, just in case ...

I have no right to stop people from trying out dangerous
things at home, nevertheless I think that someone who
does not take on a seatbelt because he 'knows' that he
'never' will be involved in an accident. But you stop
every now and then to prevent your car from getting too
fast and you have an ejection seat, just in case ...

Markus
Jan 3 '06 #142
we******@gmail.com <we******@gmail.com> schrieb:
Hmmm ... here's a rhetorical question. What is the value of a
specifying a function in the language definition if you can't even use
it -- not ever?
Despite it being a rhetorical question, here's an answer:

Some ill-meaning people insist on telling the story that
K&R designed the C programming language as one evil big
practical that unfortunately has gotten out of control.
something like that. I still don't know who exactly is pulling for the
continued support for this function, but they seem to have a lot of
influence over compiler vendors and the standards committee.


Definitely more so than they have a feeling for the needs and
wishes of programmers. But backward compatibility (even of
security holes) is a Holy Grail.

Or perhaps it's the NSA, insisting that every programming
language has to have a hole where they can sneak in...

Markus
Jan 3 '06 #143
Christian Bau wrote:
In article <dp**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:

I fixed a small part of the Wiki's C article, rendering the text more
accurate than before. Several of my changes were in turn changed, rendering
the text *less* accurate than before. I don't have time to play those
games.

Just had a look at the article, just out of curiosity. It is just good
for a laugh. If you went through it using the correct principle that the
"C Language" is the language as defined by the current standard, which
is the C99 Standard, and change everything accordingly, then some people
will suffer from a heart attack.


Someone edited it less than an hour ago. Way to go.. :)

[ http://en.wikipedia.org/wiki/C_programming_language]

This page was last modified 00:14, 3 January 2006.
Jan 3 '06 #144
Emmanuel Delahaye <em***@YOURBRAnoos.fr> schrieb:
What prevents us to edit the text in a more balanced way ?
The fear or even knowledge that it may not be worth the effort?

I always try to make changes in such a way, that a potential 'reverter'
gets (oh man, this 'gets' gets me everywhere tonight) at least a hint on
where or why he was wrong.

I just edited the "x[i] is equivalent to *(x + i*sizeof(x))"
crap in the section "unification of arrays and pointers".

I tried to do my best, but I'm still not completely
satisfied with the paragraph. Especially the end of it, which in fact
just repeats what has been said two or three sentences before,
but in a way that could give new insight to a potential reader,
so I didn't change it (yet).
Il have made
some modifications myself.
I'm glad that you reverted some of them yourself ;-)
It's simple and easy.
Sure, but the '*(x + i*sizeof(x))' error escaped you. :-)
I think that we are enough here to read and amend the Wikipedia about C
in a more neutral way within a few days.


I'm afraid that there are enough morons out there to try and vandalize
it back to it's actual crappy state within even fewer days. And I'm afraid
(or glad, that depends ;-) that I've better and more important things to do.

Better as in 'better suited to earn my living' ...

There are lives that depend on the quality of my work.
One that is particularly valuable to me is my own.

BTW, isn't there a better place to discuss this?
The discussion page of the article could be a starting place.

Markus
Jan 3 '06 #145
Markus Becker said:
James Dow Allen <jd*********@yahoo.com> schrieb:
Or do you
think strcpy() should be barred also?


Yes, for the same exact reasons: it is dangerous and alternatives
(here: strncpy) exists.


strcpy is *not* dangerous if used correctly, whereas gets is.
strncpy is *not* a plug-in replacement for strcpy.
strncpy is *not* safer than strcpy.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jan 3 '06 #146
In article <dp**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
Markus Becker said:
James Dow Allen <jd*********@yahoo.com> schrieb:
Or do you
think strcpy() should be barred also?


Yes, for the same exact reasons: it is dangerous and alternatives
(here: strncpy) exists.


strcpy is *not* dangerous if used correctly, whereas gets is.
strncpy is *not* a plug-in replacement for strcpy.
strncpy is *not* safer than strcpy.


strncpy contains two wonderful traps:

1. strncpy fills the destination beyond the length of the copied string
with zeroes. If you have a big buffer, then this is costly. Copying a
million short strings with strcpy is no sweat, copying them into a 5 MB
buffer with strncpy will take an hour.

2. If the destination buffer is not large enough for the source string,
there will be no trailing zero anywhere in the destination. In other
words, the result is not a valid C string. Using it anywhere is asking
for trouble. For example

char buffer1 [10];
char buffer2 [20];
char* p = "Hello, world!");

strncpy (buffer1, p, sizeof (buffer1));
strncpy (buffer2, buffer1, sizeof (buffer2));

invokes undefined behavior.
Jan 3 '06 #147
Richard Heathfield <in*****@invalid.invalid> schrieb:
strcpy is *not* dangerous if used correctly, whereas gets is.
You're right, there's no chance to use gets in a way that
makes it safe. But strcpy can be used in an unsafe way, the
safe way would be to check if the length of the source
string does not exceed the available size of the destination
buffer and act accordingly if it does. The 'alternative'
would be to use strncpy with an n of one less than the
capacity of the destination.

When I read the man pages regarding gets and strcpy,
they mention BUGS and dangerous and such in the case
of gets -> this is clearly dangerous.
In the case of strcpy I read "the buffer that dst points
to has to be big enough and the too strings must not
overlap" -> this _can_ be made safe, but it is tedious(sp?).

In my 'definition' that a hint that there are a few traps
and for this reason it makes strcpy potentially dangerous
for me. But as I know you and your skills, I'm eager
to learn something... and I', quite sure you come up
with a solution or explanation that I haven't thought
of yet.

So what do you mean by 'if used correctly' regarding both
strcpy and gets? IMHO the only 'correct' use of gets
it to NOT use gets. Never. There are several possibilities
to use strcpy correctly, but all involve calls to other
functions, an "if ()" and an "else strncpy(...)", checking
if the strings overlap or not and so on..

So why not use strncpy all times?

Because your environment is so that you _know_ that
src fits in dst, e.g. when both buffers are of the
same size and it _can't_ be that src is longer than
dst can hold?

Then gets is safe, too. Namely when I can be sure that
the length of the string that gets will read from
stdin will fit into my buffer, e.g. when some file
of known structure or the output of a program that
guarantees the length of its output does not exceed
a given value is connected to my stdin.

But I'm sure that you cannot mean this.
strncpy is *not* a plug-in replacement for strcpy.
Who claimed that it was? I said it is an alternative,
because IMHO it is similar enough.
And in this same way fgets relates in my world to gets:
Use it instead, give it the length of your destination
buffer and stdin as FILE*, so it is an 'alternative'.
strncpy is *not* safer than strcpy.


Sure, one can use it with unsafe parameters as well.
strcpy w/o context is no more dangerous than strncpy, both can
be used in safe and unsafe ways. But you can predict its behaviour
and control it because all information is available before the
call to any of those both functions. I also agree that gets is
unsafe and there is no way to make it safe, but:

Since I work in the evil world outside, where I have to make
sure that code that is produced by me or programmers that I'm res-
ponsible for _is_ safe, and will stay safe, I have
a slightly different notion of 'safe' than you have.

It's more easy to enforce a coding rule regarding string copying
that reads like this:

Always use "strncpy(dst,src,CAPACITY_OF_DST-1);"

as compared to this:

if (strlen(src)<=CAPACITY_OF_DST) strcpy(dst,src);
else /* do something accordingly, which will be: */
strncpy(...);

So for 'me', strncpy is safer than strcpy and if I try to use
strcpy correctly I will need to program a call to strncpy anyway
if the length of src gets (oh my, this word again) greater than
the capacity of the buffer pointed to by dst.

What would be the 'proven' way of using strcpy in a safe
way without needing strncpy as a fallback? I wouldn't be
surprised if I had overlooked something obvious. Sometimes
I cannot see the wood for the trees, you know. Especially
after a long night like this...

Markus
Jan 3 '06 #148
On Tue, 03 Jan 2006 10:27:28 +0100, Markus Becker wrote:
[arguing by example that strncpy is safer than strcpy]
It's more easy to enforce a coding rule regarding string copying that
reads like this:

Always use "strncpy(dst,src,CAPACITY_OF_DST-1);"
This has the overhead of copying (CAPACITY_OF_DST - 1 - strlen(src)) zero
bytes /every/ time the destination buffer's capacity is greater than the
source string's length (plus terminating '\0').

It also silently truncates strings that are oversize: this semantic is not
universally appropriate. I'd say then that the above snippet is less safe
than the one below, since you have no opportunity to take other action on
oversize strings.
as compared to this:

if (strlen(src)<=CAPACITY_OF_DST) strcpy(dst,src);
....which avoids the redundant copying overhead. Often the call to
strlen(src) is required for a prior operation and its result is at hand
anyhow. (the comparison shouldn't include an equality test btw)
else /* do something accordingly, which will be: */
strncpy(...);
Well, if truncating the string is appropriate semantics, then fine.
Another possibility that may be appropriate is to (re)assign a buffer
large enough to hold the string. At least this code snippet gives you the
opportunity to take that action.

[...] What would be the 'proven' way of using strcpy in a safe way without
needing strncpy as a fallback? I wouldn't be surprised if I had
overlooked something obvious.


Perhaps the obvious in some situations is as you've written, and taking
whatever error action is appropriate if a (re)assignment of a large enough
buffer fails in the 'else' branch. That action might be to print an
out-of-mem warning, log to a file, ask the user whether they want to
retry, etc.

[...]
--
http://members.dodo.com.au/~netocrat
Jan 3 '06 #149

Christian Bau wrote:

Hello,
In article <dp**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
Markus Becker said:
James Dow Allen <jd*********@yahoo.com> schrieb:

> Or do you
> think strcpy() should be barred also?

Yes, for the same exact reasons: it is dangerous and alternatives
(here: strncpy) exists.


strcpy is *not* dangerous if used correctly, whereas gets is.
strncpy is *not* a plug-in replacement for strcpy.
strncpy is *not* safer than strcpy.


strncpy contains two wonderful traps:

1. strncpy fills the destination beyond the length of the copied string
with zeroes. If you have a big buffer, then this is costly. Copying a
million short strings with strcpy is no sweat, copying them into a 5 MB
buffer with strncpy will take an hour.

2. If the destination buffer is not large enough for the source string,
there will be no trailing zero anywhere in the destination. In other
words, the result is not a valid C string. Using it anywhere is asking
for trouble. For example

char buffer1 [10];
char buffer2 [20];
char* p = "Hello, world!");

strncpy (buffer1, p, sizeof (buffer1));
strncpy (buffer2, buffer1, sizeof (buffer2));

invokes undefined behavior.


Agreed.

To avoid the dangers of the two points above, I would use something
like this in my programs:

#define MAXCH_BUF1 10
#define MAXCH_BUF2 20

char buffer1 [ MAXCH_BUF1 + 1 ];
char buffer2 [ MAXCH_BUF2 + 1 ];
size_t lngSrc = 0, lngDst = 0;

char* p = "Hello, world!";

lngSrc = strlen(p);
lngDst = (lngSrc > MAXCH_BUF1 ) ? MAXCH_BUF1 : lngSrc ;
strncpy (buffer1, p, lngDst+1);

lngSrc = strlen(buffer1);
lngDst = (lngSrc > MAXCH_BUF2 ) ? MAXCH_BUF2 : lngSrc ;
strncpy (buffer2, buffer1, lngDst+1);

I don't really understand the religious war between strcpy/strncpy pros
and cons since it's not really difficult for an experienced programmer
to write a safe program with one or the other.
Discussions about strcpy() and strncpy() often (always?) concern the
technical point of view but rarely the functional point of view. I
don't think strncpy() was designed to solve the lacks of strcpy() nor
to prevent a buffer overflow. At first glance for me, strncpy() seems
to be the easy way to extract a "real" subset of a string, whereas it's
an evidence that strcpy() was first designed for string copy, although
it's also possible with strcpy to extract a subset of a string from a
given starting position until the end.

Regis

Jan 3 '06 #150

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

32
by: Marcus | last post by:
We all know that the "gets" function from the Standard C Library (which is part of the Standard C++ Library) is dangerous. It provides no bounds check, so it's easy to overwrite memory when using...
57
by: Eric Boutin | last post by:
Hi ! I was wondering how to quickly and safely use a safe scanf( ) or gets function... I mean.. if I do : char a; scanf("%s", a); and the user input a 257 char string.. that creates a...
89
by: Cuthbert | last post by:
After compiling the source code with gcc v.4.1.1, I got a warning message: "/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the 'gets' function is dangerous and should not be...
280
by: jacob navia | last post by:
In the discussion group comp.std.c Mr Gwyn wrote: < quote > .... gets has been declared an obsolescent feature and deprecated, as a direct result of my submitting a DR about it (which...
104
by: jayapal | last post by:
Hi all, Whenever I use the gets() function, the gnu c compiler gives a warning that it is dangerous to use gets(). why...? regards, jayapal.
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.