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.
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 ---
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.
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.
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.
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)
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?
"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.
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)
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.
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/>
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.
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 =----
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
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/
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/
"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 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>
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). 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)
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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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)
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/>
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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <wH**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.org> wrote: In article <EP********************@maineline.net>, Chuck F. <cb********@yahoo.com> writesChris 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. )
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/>
Chris Hills wrote: Chuck F. <cb********@yahoo.com> writesChris 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/
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
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
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
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
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)
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?
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
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)
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
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
"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.
"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.
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 '('
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.
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 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
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.
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
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)
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.
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
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
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...
|
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.
|
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...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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...
|
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)...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
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...
| |