Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > strcpy implementation

Reply
Thread Tools

strcpy implementation

 
 
Seebs
Guest
Posts: n/a
 
      06-03-2010
On 2010-06-02, iC and iC++ <(E-Mail Removed)> wrote:
> I am writing a tutorial on C pointers and this is one of the better
> books I've found..


If you are at a level of expertise where you have to ask these questions,
I respectfully submit that you are probably not the right person to be
writing a tutorial on C pointers.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      06-03-2010
"iC and iC++" <(E-Mail Removed)> writes:
[...]
>> iC and iC++ wrote:
>> > I found this code in a very old book about pointers and I started
>> > playing with it and I have a question.

>>
>> > #include <stdio.h>
>> > #include <string.h>

>>
>> > main()
>> > * *{
>> > * *char x[5];
>> > * *strcpy(x, "COMPILER");

>>
>> > * *printf("%s, %u, %d, \n", x, &x, sizeof(x));

>>
>> > * *getchar();
>> > }

>>
>> > *How deos strcpy assign all the characters in the code if x is only
>> > defines as a 5 byte array?

[snip]
>
> Thats what I thought too, but it actually returns "COMPILER". That
> definitely more characters than it has been allocated. Why isn't there
> an error when there should be one. I am just curious.


There was an error. It just wasn't detected.

But I think what you meant was "Why isn't there an error *message*".

Many errors in C are classified as "undefined behavior". This means
that it's something you shouldn't do, but the implementation is not
obligated to diagnose, or even detect, the problem. Almost all
languages have such things; C has more than most. It can make C
programming tricky. Trial and error can often lead you astray;
a program that appears to work can still have serious errors.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      06-03-2010
"iC and iC++" <(E-Mail Removed)> writes:

> On Jun 2, 7:18*pm, Geoff <(E-Mail Removed)> wrote:
>> On Wed, 2 Jun 2010 15:57:34 -0700 (PDT), "iC and iC++"
>>
>> *What is the title of this book and who is the author?


There is always the possibility the code or its purpose have not been
accurately described.

> Mastering C Pointers: Tools for programming power by Robert J.
> Traister.. 1990


From the Amazon page:

Customers Who Bought This Item Also Bought

C: The Complete Reference, 4th Ed. by
Herbert Schildt

--
Ben.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-03-2010
"iC and iC++" <(E-Mail Removed)> writes:
> On Jun 2, 7:07*pm, Richard Heathfield <(E-Mail Removed)> wrote:

[100 lines deleted]
>
> you have been understood.
>
> thanks


When you post a followup, please trim the quoted text, keeping
only enough for your followup to be reasonably clear to someone
who hasn't read the parent article. In particular, please don't
quote signatures (the 4 or so lines following the "-- " marker)
unless you're actually commenting on them.

See most of the articles in this newsgroup for good examples of
how to do this.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-03-2010
Geoff <(E-Mail Removed)> writes:
[...]
> You MIGHT spot the bug in debug when your program prints garbage due
> to an unterminated string if you used strncpy(), example:
>
> strncpy(x, "COMPILER", sizeof(x));
>
> But even strncpy won't save you if the memory allocated to x was
> zero-filled prior to the copy operation.
>
> Short answer, forget strcpy exists. Use strncpy with care and remember
> if the buffer size is LESS than the string to be copied strncpy won't
> properly terminate the destination string.


I suggest that that's bad advice.

strncpy(), in contrast to most of the other standard strn*()
functions, is *not* just a safer version of strcpy() that lets you
specify a maximum length. It's designed for a very specific (and,
these days, unusual) data structure: a fixed size characters array
consisting of some number of data characters followed by zero or
more trailing null characters. (Some early Unix systems stored
file names this way, with an upper bound of 14 characters.)

If the source string is short, the target array is padded with
unnecessary extra null characters. If the source is long, the
target array will not contain a string, which will almost certainly
cause problems later on. (Whether those problems will be detected
is another matter.)

If you're able to exercise enough care to use strncpy() safely,
you're able to exercise enough care to use strcpy() safely.

strcpy() is not *inherently* dangerous. It's possible to shoot
yourself in the foot with it (as the original example demonstrates),
but with care it can be used safely; you just have to ensure,
by whatever means you like, that the target array is big enough.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-03-2010
Seebs <(E-Mail Removed)> writes:
> On 2010-06-02, iC and iC++ <(E-Mail Removed)> wrote:
>> #include <stdio.h>
>> #include <string.h>
>>
>> main()
>> {
>> char x[5];
>> strcpy(x, "COMPILER");
>>
>> printf("%s, %u, %d, \n", x, &x, sizeof(x));
>>
>> getchar();
>> }

>
>> How deos strcpy assign all the characters in the code if x is only
>> defines as a 5 byte array?

>
> By overwriting other stuff, probably. This is certainly welcome to blow up
> spectacularly, and will on some hardware.


It's also welcome to quietly do what you expected it to do. This is
arguably a much worse outcome than blowing up spectacularly.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      06-03-2010
On 2010-06-03, Jason Earl <(E-Mail Removed)> wrote:
> On Wed, Jun 02 2010, Seebs wrote:
>> If you are at a level of expertise where you have to ask these
>> questions, I respectfully submit that you are probably not the right
>> person to be writing a tutorial on C pointers.


> I respectfully disagree. Writing a tutorial is a great way to learn
> something. If you think about it you'll probably even agree with me.


No, no, I've thought about it a great deal and I still strongly disagree.

> I would bet that you learned a great deal about shell scripting by writing
> a book about the subject.


Yes. But I *started* as an experienced shell programmer who knew the
topic better than most people. And I was writing a book which, no matter
what the marketing people thought, was aimed at reasonably experienced
people.

A decent tutorial is MUCH harder to write. It's aimed at people who haven't
got the background or skills to recognize any errors you make, and who are
unequipped to evaluate the quality of your work -- and they are fairly likely
to imprint on whatever mistakes you make.

> There are certainly people that know even less about pointers than iC,
> and so tutorial could even be helpful.


A book or tutorial written by someone even moderately experienced, but not
an expert, can often be fairly harmful -- it's too easy to teach people
errors.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-03-2010
Seebs <(E-Mail Removed)> writes:
> On 2010-06-03, Jason Earl <(E-Mail Removed)> wrote:
>> On Wed, Jun 02 2010, Seebs wrote:
>>> If you are at a level of expertise where you have to ask these
>>> questions, I respectfully submit that you are probably not the right
>>> person to be writing a tutorial on C pointers.

>
>> I respectfully disagree. Writing a tutorial is a great way to learn
>> something. If you think about it you'll probably even agree with me.

>
> No, no, I've thought about it a great deal and I still strongly disagree.


I suggest that *writing* a tutorial might be a good way to learn
something. *Distributing* it (other than to experts for feedback)
might not be such a good idea.

Of course, once you've written a tutorial it might be hard to resist
the temptation to share it -- which could explain the preponderance
of lousy tutorials out there.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      06-03-2010
On 3 June, 00:09, Geoff <(E-Mail Removed)> wrote:
> On Wed, 2 Jun 2010 15:22:39 -0700 (PDT), "iC and iC++"
> <(E-Mail Removed)> wrote:


> >I found this code in a very old book about pointers and I started
> >playing with it and I have a question.

>
> >#include <stdio.h>
> >#include <string.h>

>
> >main()
> > * *{
> > * *char x[5];
> > * *strcpy(x, "COMPILER");

>
> > * *printf("%s, %u, %d, \n", x, &x, sizeof(x));

>
> > * *getchar();
> >}

>
> > How deos strcpy assign all the characters in the code if x is only
> >defines as a 5 byte array? In other words, where are the extra bytes
> >stored and how is memory for them allocated. I looked at it while
> >debugging and there were no clues there.

>
> This is a fine example of why strcpy is unsafe.


only you and Microsoft think strcpy() is unsafe. Like many other C
functions strcpy() can be used in an unsafe manner. Either don't do
that or use a safer language.

> The results you get will depend on your platform and compiler
> implementation as well as your choice of optimizations. On x86 in
> debug mode on Windows you would have to look closely to see the bug
> waiting to bite you.
>
> 5 bytes are reserved for x[] but strcpy will write 8 characters plus a
> zero termination for the string (9 chars). Overwriting something
> adjacent to x[] and on x86 that would be in the stack frame for the
> main() function. Classic buffer overrun and stack smash waiting to
> happen. If the second argument to strcpy was dependent on user input,
> you would be in a world of hurt when the blackhats want to hit you.
>
> My compiler reserves 8 bytes for the 5 chars due to alignment
> requirements.
>
> You MIGHT spot the bug in debug when your program prints garbage due
> to an unterminated string if you used strncpy(), example:
>
> * * * * strncpy(x, "COMPILER", sizeof(x));
>
> But even strncpy won't save you if the memory allocated to x was
> zero-filled prior to the copy operation.
>
> Short answer, forget strcpy exists. Use strncpy with care and remember
> if the buffer size is LESS than the string to be copied strncpy won't
> properly terminate the destination string.- Hide quoted text -


no. Forget strncpy() exists. This is my strncpy() boilerplate response

the semantics of strncpy() are non-intuitive (it's broken). So
generally
*don't* use strncpy.

/* what is wrong with this? */
char sbuff[5];
strncpy(sbuff, "bomb", 4);
printf ("%s\n", buff);

/* how many characters are written to bbuff? */
char bbuff [1000000];
strncpy(bbuff, "bomb", 1000000);

See FAQ 13.2 "Why does strncpy() not always place a '\0'
terminator in the destination string?


 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      06-03-2010
On 2010-06-03, Keith Thompson <(E-Mail Removed)> wrote:
> I suggest that *writing* a tutorial might be a good way to learn
> something. *Distributing* it (other than to experts for feedback)
> might not be such a good idea.


That may be a good point.

My experience has been that trying to teach something before I understand
it well enough tends to make me firm up bad ideas, though, because I have
to talk as though they're known truths rather than speculations...

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
strcpy - my implementation arnuld C Programming 64 09-11-2008 12:49 AM
strcpy and the copy constructor RonHiler C++ 8 10-19-2004 06:30 AM
C++ Compiler with a -Wwarn-use-of-strcpy or similar option?? Paul Sheer C++ 4 09-14-2004 08:38 PM
C++ Compiler with a -Wwarn-use-of-strcpy or similar option?? Paul Sheer C++ 7 09-10-2004 05:07 PM
strcpy Mike Mimic C++ 9 05-17-2004 08:12 PM



Advertisments