By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,655 Members | 1,005 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,655 IT Pros & Developers. It's quick & easy.

Under what circumstances will this use of strncpy fail?

P: n/a
Ron
#define MAX_SIZE 512

char mybuffer[MAX_SIZE+1];

void myfunction( const char* src )
{
if( src == null ) { return; }

/* A core dump is occuring here */
strncpy( mybuffer, src, MAX_SIZE );
mybuffer[ MAX_SIZE ] = 0;
}
A core dump is occuring on line 10. If src is not null when I call
strncpy, is there anything about its contents that could cause strncpy
to fail? My guess is that there is no way the contents of src could
cause the core, so the pointer itself is bad, even if it is not null.
However, inspecting the calling code, src looks fine. The only thing
I can't inspect (easily) is the contents of src. I can't think of any
way the contents can be the root cause, but maybe someone reading this
knows better.

Mar 9 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Ron wrote On 03/09/07 14:44,:
#define MAX_SIZE 512

char mybuffer[MAX_SIZE+1];

void myfunction( const char* src )
{
if( src == null ) { return; }

/* A core dump is occuring here */
strncpy( mybuffer, src, MAX_SIZE );
mybuffer[ MAX_SIZE ] = 0;
}
A core dump is occuring on line 10. If src is not null when I call
strncpy, is there anything about its contents that could cause strncpy
to fail? My guess is that there is no way the contents of src could
cause the core, so the pointer itself is bad, even if it is not null.
However, inspecting the calling code, src looks fine. The only thing
I can't inspect (easily) is the contents of src. I can't think of any
way the contents can be the root cause, but maybe someone reading this
knows better.
What is `null' and where is it defined -- or have
you posted a paraphrase instead of the actual code?

If there really is a `null' floating around, maybe
someone has called myfunction(NULL) and the test fails
to detect it.

But if `null' is really `NULL' and <string.hhas
been #included, I can only guess that `src' points to
someplace bogus, to an address that isn't even part of
your program. Or perhaps to an address within MAX_SIZE
bytes of the end of a chunk of your program's memory,
with no '\0' between it and the edge of the world. You
might also get into trouble if `src' points to a location
somewhere inside `mybuffer'.

Just guessing, I'm afraid ...
--
Er*********@sun.com
Mar 9 '07 #2

P: n/a
Ron
On Mar 9, 3:23 pm, Eric Sosman <Eric.Sos...@sun.comwrote:
>
What is `null' and where is it defined -- or have
you posted a paraphrase instead of the actual code?
Sorry, I've been programming in java alot lately. I meant NULL, and
I'm not suspicious of the validation of the src pointer.
But if `null' is really `NULL' and <string.hhas
been #included, I can only guess that `src' points to
someplace bogus
...
Just guessing, I'm afraid ...
Actually, I appreciate your guesses! I draw the same conclusion -
somehow src must be bad.

Unfortunatley I can't see a problem through inspection. The caller
uses new to allocate an array of char for src. The caller then fills
src with data from a stream, and null terminates src. All of these
operations seem to be properly validated and range checked. I cannot
see any way that memory for src was delete'd or that src was
intentionally reassigned before the call to myfunction. So...

If the value of the src pointer does not change between caller's new
operation and my strncpy, is it possible that the caller could have
successfully used src without causing a core dump there?

If the answer to that is 'no' (and I think it is), I think that means
src was good while the caller was using it, but was unintentionally
changed after that, but before the call to strncpy, such as by a
memory trampling bug or some such. This is the only explanation I can
come up with.

Ahem - I forgot to mention that the problem is intermittent. :) To
give more context, the caller is reading records from a stream, and
myfunction needs to copy one of the strings in the record. Many
records will get processed before the core dump. I have no control
over the code that writes or reads these records, or how src is
initialized or used before it gets to myfunction. But strncpy is
where the core dump happens, so I get to debug. :)

I guess my purpose for posting is to confirm that the only thing that
can go wrong here is the caller gives myfunction a bad pointer (i.e.
myfunction is written correctly and the contents of src don't matter).

Mar 9 '07 #3

P: n/a
Ron wrote:
>
Ahem - I forgot to mention that the problem is intermittent. :) To
give more context, the caller is reading records from a stream, and
myfunction needs to copy one of the strings in the record. Many
records will get processed before the core dump. I have no control
over the code that writes or reads these records, or how src is
initialized or used before it gets to myfunction. But strncpy is
where the core dump happens, so I get to debug. :)
Odds are, something else completely unrelated to your function is doing
something nasty to the head. The problem just happens to reveal its
self in your code.

If your implementation supports it, use a memory bounds checker.

--
Ian Collins.
Mar 9 '07 #4

P: n/a
In article <11**********************@p10g2000cwp.googlegroups .com>,
Ron <bn*****@gmail.comwrote:
>Unfortunatley I can't see a problem through inspection. The caller
uses new to allocate an array of char for src.
There is no such thing as "new" in C. Presumably this is C++.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Mar 9 '07 #5

P: n/a
Ian Collins wrote:
Ron wrote:
>>Ahem - I forgot to mention that the problem is intermittent. :) To
give more context, the caller is reading records from a stream, and
myfunction needs to copy one of the strings in the record. Many
records will get processed before the core dump. I have no control
over the code that writes or reads these records, or how src is
initialized or used before it gets to myfunction. But strncpy is
where the core dump happens, so I get to debug. :)

Odds are, something else completely unrelated to your function is doing
something nasty to the head. The problem just happens to reveal its
self in your code.
"something nasty to the heap"

--
Ian Collins.
Mar 9 '07 #6

P: n/a
Ian Collins said:
Ian Collins wrote:
<snip>
>Odds are, something else completely unrelated to your function is
doing
something nasty to the head. The problem just happens to reveal its
self in your code.
"something nasty to the heap"
Ohhhh, I dunno - I think you got it right the first time. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 9 '07 #7

P: n/a
Richard Heathfield wrote:
Ian Collins said:

>>Ian Collins wrote:


<snip>
>>>Odds are, something else completely unrelated to your function is
doing
something nasty to the head. The problem just happens to reveal its
self in your code.

"something nasty to the heap"


Ohhhh, I dunno - I think you got it right the first time. :-)
Exploding toilets, anyone?

--
Ian Collins.
Mar 9 '07 #8

P: n/a
Ron wrote On 03/09/07 16:46,:
On Mar 9, 3:23 pm, Eric Sosman <Eric.Sos...@sun.comwrote:
> What is `null' and where is it defined -- or have
you posted a paraphrase instead of the actual code?


Sorry, I've been programming in java alot lately. I meant NULL, and
I'm not suspicious of the validation of the src pointer.

> But if `null' is really `NULL' and <string.hhas
been #included, I can only guess that `src' points to
someplace bogus

...
> Just guessing, I'm afraid ...


Actually, I appreciate your guesses! I draw the same conclusion -
somehow src must be bad.

Unfortunatley I can't see a problem through inspection. The caller
uses new to allocate an array of char for src [...]
Aha! You are using That Other Language, the one with
the C-ish-but-not-quite-C rules, the one that puts your
helpless program at the mercy of ravenous "destructors."
You want comp.lang.c++, down the hall to the left.

--
Er*********@sun.com
Mar 9 '07 #9

P: n/a
Ian Collins wrote:
Richard Heathfield wrote:
>Ian Collins said:
>>Ian Collins wrote:

<snip>
>>>Odds are, something else completely unrelated to your function
is doing something nasty to the head. The problem just happens
to reveal its self in your code.

"something nasty to the heap"

Ohhhh, I dunno - I think you got it right the first time. :-)

Exploding toilets, anyone?
Undefined behaviour in the head? Sounds like diarhea.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Mar 10 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.