What are the common causes to null-terminated string for not having \0 character and later buffer overflow

[semut]

Given that the string is of null-terminated type. What could be the
possible causes (by experience) the string to have no null character
(\0)
and cause buffer overflow later. I know it is quite broad, just like to
find out the causes as much as possible so that I could impose stricter
checking toward my codes.

note: I could not use std::string cause it will require a total
rewrite.

thanks.

(this is a re-post from comp.lang.C++ because comp.lang.c seem more
appropriate)

[pete]

semut wrote:

>
Given that the string is of null-terminated type. What could be the
possible causes (by experience) the string to have no null character
(\0)
and cause buffer overflow later.
I know it is quite broad, just like to
find out the causes as much as possible so that
I could impose stricter
checking toward my codes.

How are you aquiring your strings?
What are you doing to them?

--
pete

[Barry Schwarz]

On 4 Dec 2006 18:19:28 -0800, "semut" <an*****@gmail.comwrote:

>Given that the string is of null-terminated type. What could be the
possible causes (by experience) the string to have no null character
(\0)
and cause buffer overflow later. I know it is quite broad, just like to

The usual suspects: design errors, coding errors, and input errors.

>find out the causes as much as possible so that I could impose stricter
checking toward my codes.

That eliminates one of the design errors.

>
note: I could not use std::string cause it will require a total
rewrite.

And also a change in newgroups. Are you coding in C or C++?
Remove del for email

[Eric Sosman]

semut wrote:

Given that the string is of null-terminated type. What could be the
possible causes (by experience) the string to have no null character
(\0)
and cause buffer overflow later. I know it is quite broad, just like to
find out the causes as much as possible so that I could impose stricter
checking toward my codes.

In my experience it is unusual for a string to lack its
terminator. (Strictly speaking, it is impossible: a string,
by definition, has a terminator. Let me say instead that it
is unusual for an array that is "supposed to be a string" to
lack a terminator.)

On those few occasions I've seen it happen, it's almost
always been the result of strncpy(). Some people have come
to believe that strncpy() is "a safer strcpy()," but they
have been deluded. In fact, strncpy() used naively simply
trades one error for a different one: instead of overrunning
the too-small buffer right now, it leaves an unterminated
non-string poison pill for some later victim to choke on.

If non-terminated "string-like things" are actually a
problem in your code base, I think your first step should be
to hunt down every strncpy() call and require the person who
wrote the call to explain just why he did it. (His explanation
may turn out to be satisfactory, but I'd bet against it. I've
heard that some style-checking programs behave this way with
the word "comprised:" they don't bother analyzing the sentence,
but simply flag every "comprised" as incorrect. It's faster
than checking, and nearly always right.)

--
Eric Sosman
es*****@acm-dot-org.invalid

[CBFalconer]

semut wrote:

>
Given that the string is of null-terminated type. What could be
the possible causes (by experience) the string to have no null
character (\0) and cause buffer overflow later. I know it is quite
broad, just like to find out the causes as much as possible so
that I could impose stricter checking toward my codes.

Failure to write the '\0' as the string terminator.

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

[Thad Smith]

semut wrote:

Given that the string is of null-terminated type. What could be the
possible causes (by experience) the string to have no null character
(\0)
and cause buffer overflow later. I know it is quite broad, just like to
find out the causes as much as possible so that I could impose stricter
checking toward my codes.

Typical causes are copying strings into an array that is shorter than
the source. It might be done with strcpy, strncpy, strcat, sprintf, or
the programmer's own copy loop.

--
Thad

[semut]

pete wrote:

semut wrote:

Given that the string is of null-terminated type. What could be the
possible causes (by experience) the string to have no null character
(\0)
and cause buffer overflow later.
I know it is quite broad, just like to
find out the causes as much as possible so that
I could impose stricter
checking toward my codes.

How are you aquiring your strings?
What are you doing to them?

--
pete

It is some kind of custom memory allocator which allocate memory based
on a share memory content.

[Richard Heathfield]

semut said:

Given that the string is of null-terminated type. What could be the
possible causes (by experience) the string to have no null character
(\0)
and cause buffer overflow later.

None. If it doesn't have a null character terminating it, it isn't a string.

When you choose to use a particular data format, it is your responsibility
to ensure that the requirements of that format are met. For example, if you
choose to use a binary search tree, it is your responsibility to ensure
that the tree remains ordered whenever you add, remove, or move nodes. If
you fail to do this, you don't *have* a binary search tree. If you choose
to use a double-linked list, it is your responsibility to ensure that every
node points to its previous node (or NULL if there isn't a previous node)
and its next node (or NULL if there isn't a next node). If you fail to do
this, you don't *have* a double-linked list.

With strings, the requirements are much gentler - all you have to do is
ensure that you don't exceed your memory availability and that you have a
null terminator at the end of the data, taking care to replace it if it
gets erased for some reason (as it might, when copying substrings about or
getting your hands dirty with pointers). But if you fail to do this, you
don't *have* a string.

How many different ways are there to foul up a binary search tree?
Infinitely many. But they all have one shared characteristic: they break
the binary search tree model. How many different ways are there to foul up
a double-linked list? Infinitely many. But they all have one shared
characteristic: they break the double-inked list model.

And how many different ways are there to foul up a string? Infinitely many.
But they all have one shared characteristic: they break the string model.

So the answer is simple: don't break the model.

I know it is quite broad, just like to
find out the causes as much as possible so that I could impose stricter
checking toward my codes.

When writing to a string:

1) Always know your bounds.
2) Never write outside your bounds.
3) Ensure the string is null-terminated before you give up control over it.

note: I could not use std::string cause it will require a total
rewrite.

std::string is just a syntax error, so I don't see how it is relevant.

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