Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > strcpy overlapping memory

Reply
Thread Tools

strcpy overlapping memory

 
 
Ike Naar
Guest
Posts: n/a
 
      12-10-2010
On 2010-12-10, arnuld <(E-Mail Removed)> wrote:
> What about this situation where size of dest is lesser than size of
> source. It does Segfault but it Segfaults after printing "WOW..."
> statement, can't understand why. It should not print the message because
> it has already Segfaulted in strcpy().
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> char* src = "000000000000000000000000";
> char dest[6] = {0};
>
> strcpy(dest, src);
>
> printf("WOW!... SRC is larger thab DEST but strcpy still works\n");
>
> return 0;
> }
>
>===================== OUTPUT =========================
> [arnuld@dune programs]$ gcc -ansi -pedantic -Wall -Wextra strcpy.c
> [arnuld@dune programs]$ ./a.out
> WOW!... SRC is larger thab DEST but strcpy still works
> Segmentation fault
> [arnuld@dune programs]$


It probably doesn't segfault *in* strcpy().
It's very well possible that strcpy() finishes the job, filling
dest[] and clobbering over memory near dest[]. You shouldn't be
surprised if it clobbers, for instance, the return adress pointing
to the location from where main() was called, and that the segfault
occurs on return from main().
 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      12-10-2010

"tm" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 7 Dez., 01:46, "BartC" <(E-Mail Removed)> wrote:
>> "Keith Thompson" <(E-Mail Removed)> wrote in message


>> > Check for NULL and do what?

>>
>> Pretend it's ""?

>
> I remember that under HPUX NULL and "" were interchangeable.
> A very very bad idea. It made the job of porting a program
> from HPUX to SGI harder.


Only because SGI hadn't thought of it too!

> Strings were initialized with NULL
> all over the place and nobody cared. The development team
> (they mainly used HPUX) was not even aware of the difference
> between NULL and "". And when I explained it to them, they
> could hardly believe there is a difference. It really
> hindered their understanding of pointers and strings.
>
> I had to introduce a layer of macros and functions for
> every string function (strcmp, strlen, strcpy, ...) like
>
> size_t my_strlen (const char *s)
> {
> if (s == NULL) {
> return 0;
> } else {
> return strlen(s);
> }
> }
>
> #define strlen(s) my_strlen(s)


This demonstrates my point exactly. If strlen() behaved like my_strlen(),
then would be no problem.

If NULL is not taken care of by the standard functions, then these NULL
checks have to be sprinkled all over the code.

--
Bartc

 
Reply With Quote
 
 
 
 
tm
Guest
Posts: n/a
 
      12-10-2010
On 10 Dez., 10:07, "BartC" <(E-Mail Removed)> wrote:
> "tm" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
> > On 7 Dez., 01:46, "BartC" <(E-Mail Removed)> wrote:
> >> "Keith Thompson" <(E-Mail Removed)> wrote in message
> >> > Check for NULL and do what?

>
> >> Pretend it's ""?

>
> > I remember that under HPUX NULL and "" were interchangeable.
> > A very very bad idea. It made the job of porting a program
> > from HPUX to SGI harder.

>
> Only because SGI hadn't thought of it too!
>
>
>
> > Strings were initialized with NULL
> > all over the place and nobody cared. The development team
> > (they mainly used HPUX) was not even aware of the difference
> > between NULL and "". And when I explained it to them, they
> > could hardly believe there is a difference. It really
> > hindered their understanding of pointers and strings.

>
> > I had to introduce a layer of macros and functions for
> > every string function (strcmp, strlen, strcpy, ...) like

>
> > size_t my_strlen (const char *s)
> > {
> > *if (s == NULL) {
> > * *return 0;
> > *} else {
> > * *return strlen(s);
> > *}
> > }

>
> > #define strlen(s) my_strlen(s)

>
> This demonstrates my point exactly. If strlen() behaved like my_strlen(),
> then would be no problem.


Nobody hinders you to define this macros and functions.
But keep in mind: This functions do not work according to
the C standard.

BTW. It is not just the string functions. What happens
when you want to access the characters of a string
yourself? You have to check for NULL before you do s[0].
While C strings are '\0' terminated NULL is not. Except
when NULL[0] succeeds and returns '\0'. But that opens
another can of worms, since it allows dereferencing NULL
without segfault.

When NULL and "" are equivalent you can easily initialize
strings with NULL. But you could also initialize them
with "" instead. I think you probably want an automatic
memory management for strings, but this is byond the concept
of char* strings.

Having two distinct values with the same meaning (like
NULL and "") is IMHO generally not a good idea.

> If NULL is not taken care of by the standard functions, then these NULL
> checks have to be sprinkled all over the code.


No, I consider a NULL string an error. In most cases I do
not check for NULL strings. I check when the momory for
a string is requested with malloc, but not afterwards.
I really want that my program segfaults when a NULL
string is used.

BTW. I also think that string library functions, which
check for NULL all the time, would be much slower.
Note that the C standard string library functions do not
check for NULL and create a segfault when it happens. The
segfault is caused by a different mechanism, which does
not slow down the string functions.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      12-10-2010
On 12/10/2010 4:07 AM, BartC wrote:
>
> "tm" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> [...]
>> I had to introduce a layer of macros and functions for
>> every string function (strcmp, strlen, strcpy, ...) like
>>
>> size_t my_strlen (const char *s)
>> {
>> if (s == NULL) {
>> return 0;
>> } else {
>> return strlen(s);
>> }
>> }
>>
>> #define strlen(s) my_strlen(s)

>
> This demonstrates my point exactly. If strlen() behaved like
> my_strlen(), then would be no problem.


No, the problem would just change its nature and move from
one place to another. Instead of crashing, the program might (for
example) just print nothing at all in the "Amount" field of a
paycheck -- delighting the worker who gets to fill in whatever he
likes, but displeasing the company who paid for the check-writing
software ...

> If NULL is not taken care of by the standard functions, then these NULL
> checks have to be sprinkled all over the code.


If NULL means something different from "", the program must check
for the difference. If "" means something different from "purple",
the program must check for the difference. What's the, er, difference?

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      12-10-2010
"Eric Sosman" <(E-Mail Removed)> wrote in message
news:idt955$vde$(E-Mail Removed)-september.org...
> On 12/10/2010 4:07 AM, BartC wrote:
>>
>> "tm" <(E-Mail Removed)> wrote in message


>>> I had to introduce a layer of macros and functions for
>>> every string function (strcmp, strlen, strcpy, ...) like
>>>
>>> size_t my_strlen (const char *s)
>>> {
>>> if (s == NULL) {


>>> #define strlen(s) my_strlen(s)

>>
>> This demonstrates my point exactly. If strlen() behaved like
>> my_strlen(), then would be no problem.

>
> No, the problem would just change its nature and move from
> one place to another. Instead of crashing, the program might (for
> example) just print nothing at all in the "Amount" field of a
> paycheck -- delighting the worker who gets to fill in whatever he
> likes, but displeasing the company who paid for the check-writing
> software ...


But with crashing software *nobody* would get paid. And if an application
used "", then the field would be blank anyway.

If a blank field is an error, it will be obvious when the field appears
'blank'. Not so obvious when there's a seg fault or whatever.

>> If NULL is not taken care of by the standard functions, then these NULL
>> checks have to be sprinkled all over the code.

>
> If NULL means something different from "", the program must check
> for the difference. If "" means something different from "purple",
> the program must check for the difference. What's the, er, difference?


If. Usually a string is a string, you might not do anything different with a
0-length string compared with an N-length one.

But it is a pain then to have to check for NULLs (which I tend to do with
functions taking string arguments).

At the moment I might write:

if (s==NULL) return NULL;
slen = strlen(s);
if (slen==0) return NULL;

And mention in the specs that NULL is an acceptable argument equivalent to
an empty string.

But wouldn't it be useful to be able to omit that first check?

--
bartc

 
Reply With Quote
 
Ike Naar
Guest
Posts: n/a
 
      12-10-2010
On 2010-12-10, BartC <(E-Mail Removed)> wrote:
> But it is a pain then to have to check for NULLs (which I tend to do with
> functions taking string arguments).
>
> At the moment I might write:
>
> if (s==NULL) return NULL;
> slen = strlen(s);
> if (slen==0) return NULL;
>
> And mention in the specs that NULL is an acceptable argument equivalent to
> an empty string.


There a many categories of invalid pointers: null pointer, indeterminate
pointer, pointer to array of char with no zero terminator, pointer to short
buffer, etc. Which categories do you find acceptable arguments?
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      12-10-2010


"Ike Naar" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 2010-12-10, BartC <(E-Mail Removed)> wrote:
>> But it is a pain then to have to check for NULLs (which I tend to do with
>> functions taking string arguments).
>>
>> At the moment I might write:
>>
>> if (s==NULL) return NULL;
>> slen = strlen(s);
>> if (slen==0) return NULL;
>>
>> And mention in the specs that NULL is an acceptable argument equivalent
>> to
>> an empty string.

>
> There a many categories of invalid pointers: null pointer, indeterminate
> pointer, pointer to array of char with no zero terminator, pointer to
> short
> buffer, etc. Which categories do you find acceptable arguments?


We're talking a valid pointer to a zero-terminated string, or a NULL value.
Nothing much can be done about invalid pointers.

NULL meaning 'empty value' is not so useful for other types which need other
mechanisms to determine the size of the data.

It's possible that a rogue string pointer might end up with a NULL value
that is then treated as an empty string rather than cause a crash. And
possibly that is a more difficult bug to pick up than a rogue pointer into
random memory, which will likely give obviously wrong results.

But then, NULL is also used for signalling, which suffers from the same
problem: is that NULL value intentional, or accidental?

--
Bartc



 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      12-10-2010
On 2010-12-10, arnuld <(E-Mail Removed)> wrote:
> What about this situation where size of dest is lesser than size of
> source. It does Segfault but it Segfaults after printing "WOW..."
> statement, can't understand why. It should not print the message because
> it has already Segfaulted in strcpy().


No it hasn't.

Invoking undefined behavior is not the same as segfaulting. It's quite
possible for the undefined behavior to, instead of crashing, set things
up so that you will crash at some unspecified point in the distant future.

You have a fascinating cognitive map of C, but it's basically totally wrong.

-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!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-10-2010
"BartC" <(E-Mail Removed)> writes:
> "tm" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On 7 Dez., 01:46, "BartC" <(E-Mail Removed)> wrote:
>>> "Keith Thompson" <(E-Mail Removed)> wrote in message

>
>>> > Check for NULL and do what?
>>>
>>> Pretend it's ""?

>>
>> I remember that under HPUX NULL and "" were interchangeable.
>> A very very bad idea. It made the job of porting a program
>> from HPUX to SGI harder.

>
> Only because SGI hadn't thought of it too!


Only because SGI *and everyone else in the world* didn't do it the way
HPUX did, and because the HPUX behavior isn't guaranteed by the
standard.

[...]

> If NULL is not taken care of by the standard functions, then these NULL
> checks have to be sprinkled all over the code.


Or the code could have been written correctly in the first place so it
never tries to pass a null pointer to a string function.

Yes, writing software correctly can be non-trivial, but keeping a
consistent mental model ("" and NULL are two different things)
makes it easier.

--
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
 
Default User
Guest
Posts: n/a
 
      12-10-2010
"arnuld" <(E-Mail Removed)> wrote in message
news:4d01d425$0$23759$(E-Mail Removed)...

> What about this situation where size of dest is lesser than size of
> source. It does Segfault but it Segfaults after printing "WOW..."
> statement, can't understand why. It should not print the message because
> it has already Segfaulted in strcpy().


There is no defined behavior for undefined behavior.



Brian


 
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 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
Declarations of structs, and arrays seem to be overlapping in memory..?! David Thorp C Programming 4 09-01-2003 11:46 PM



Advertisments