What could normally causes the string to have no null terminated

[semut]

Given that the string is of null terminated type. What could be the
possible causes (by experience) the string to have no null terminated
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.

 

[Emmanuel Deloget]

semut a écrit :

Given that the string is of null terminated type. What could be the
possible causes (by experience) the string to have no null terminated
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.

I can only think about the string construction, but without more
information about how you construct it, I'm not sure I will be able to
help more. Remember that you are supposed to add this nul (not null
BTW) character by yourself, or to use functions that automagically add
it when recopying the input buffer(s) (if it is present). snprintf,
strncpy, strncat and other related functions might NOT copy the end of
the string (including the nul char) if the n parameter is too small.

Also remember that using std::string might need you to rewrite
everything, but will also save your time when you hit such kind of
nasty bugs. All in all , it still might be a win in the end

Regards,

-- Emmanuel Deloget, Artware

 

[Michal Nazarewicz]

Given that the string is of null terminated type. What could be the
possible causes (by experience) the string to have no null terminated
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.

I guess that question would be better asked at comp.lang.c as people
there are used to such strings whereas (as I presume) at comp.lang.c++
people prefer std::string.

As to your question probably using gets(), strcpy(), sprintf() instead
of fgets(), strncpy(), snprintf() etc. Also pay attention to
strncpy() as it does not in all case write the null terminator.

 

[eriwik]

Given that the string is of null terminated type. What could be the
possible causes (by experience) the string to have no null terminated
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.

Just one of many examples:
If you create a buffer (char*) of some size and use some function that
places text in this buffer, but you forget to take into account the \0
when specifying the size of the buffer in the function call. This will
cause the function to put the \0 outside the buffer (so far maybe no
real harm done). The for some reason the \0 outside the buffer changes
(that memory-space was used by a variable which you just assigned a
value to. Now you don't have a \0 at the end of the string and that
will give you lots of hours trying to figure out what went wrong.

 

[Ondra Holub]

semut napsal:

Given that the string is of null terminated type. What could be the
possible causes (by experience) the string to have no null terminated
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.

In general, every function which gets parameter of type char* is able
to destroy the given string. You should pass parameters to all
functions, which cannot change it as const char*. Of course, you can
still make some ugly typecasts from const value to non-const value, but
such cases should be omitted.

But as was said above, I would rewrite it to use std::string.

 

[Geo]

Given that the string is of null terminated type. What could be the
possible causes (by experience) the string to have no null terminated

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.

Mostly caused by buffer size problems.

Some guidlines to reduce the possibility, don't use
sprintf
memcpy
strcat
scanf
gets
strftime

take care when using
fgets (make sure size is < buffer length)
strcpy

I'm sure there's loads more potentially problem functions

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

You pays your money, you takes your choice.... in the long run it's
probably easier to re-write.

 

[Howard]

Remember that you are supposed to add this nul (not null BTW)

In the C++ language, it's NULL, not nul. (Or even null... C++ is
case-sensitive.) The only place I've seen NUL (not nul) is in the
specifications of the ASCII character set. I see null used often in plain
text, especially when talking about "null-terminated strings". Personally,
I prefer to say "NULL-terminated", since that's C++-specific, and every C++
programmer knows I mean that there's a 0 at the end. But "nul"? I've never
seen that anywhere that I can recall.

-Howard

 

[Geo]

But "nul"? I've never
seen that anywhere that I can recall.

Pascal and Ada I think.

 

[Andre Kostur]

In the C++ language, it's NULL, not nul. (Or even null... C++ is
case-sensitive.) The only place I've seen NUL (not nul) is in the
specifications of the ASCII character set. I see null used often in
plain text, especially when talking about "null-terminated strings".
Personally, I prefer to say "NULL-terminated", since that's
C++-specific, and every C++ programmer knows I mean that there's a 0
at the end. But "nul"? I've never seen that anywhere that I can
recall.

To me... NULL says pointer. nul says '\0'. So if you typed to me "NULL-
terminated string", I'd first be temporarily confused as to why you're
trying to put a pointer into a std::string, realize you're talking about a
C-style string, and then wonder the same thing (why are you trying to stick
a pointer into a char).

 

[Howard]

To me... NULL says pointer. nul says '\0'. So if you typed to me "NULL-
terminated string", I'd first be temporarily confused as to why you're
trying to put a pointer into a std::string, realize you're talking about a
C-style string, and then wonder the same thing (why are you trying to
stick
a pointer into a char).

Perhaps 0-terminated (or zero-terminated) would be more appropriate?

I've also seen "nil" (which is what Pascal uses), but not "nul". But that's
for pointers only. (Pascal uses length-encoded strings, not null-terminated
ones.)

In any case, there's no "nul" mentioned in the C++ standard. It's not even
in wikipedia (whereas "null" is). If you look up "nul" in Yahoo's online
dictionary, it takes you to "null". And Webster's refers you to "null".

-Howard

 

[semut]

and cause buffer overflow later. I know it is quite broad, just like
to

Mostly caused by buffer size problems.

Some guidlines to reduce the possibility, don't use
sprintf
memcpy
strcat
scanf
gets
strftime

take care when using
fgets (make sure size is < buffer length)
strcpy

I'm sure there's loads more potentially problem functions



You pays your money, you takes your choice.... in the long run it's
probably easier to re-write.

thanks everyone for the enlightenment.

 

[Emmanuel Deloget]

Howard a écrit :

Perhaps 0-terminated (or zero-terminated) would be more appropriate?

I've also seen "nil" (which is what Pascal uses), but not "nul". But that's
for pointers only. (Pascal uses length-encoded strings, not null-terminated
ones.)

In any case, there's no "nul" mentioned in the C++ standard. It's not even
in wikipedia (whereas "null" is). If you look up "nul" in Yahoo's online
dictionary, it takes you to "null". And Webster's refers you to "null".

-Howard

Apologies. The name of the character, as per the ASCII table
definition, is NUL, but it should be refered either as the NUL
character or the null character (but not the nul character).

On the other end, neither the C standard nor the C++ one relie on the
ASCII table to express characters (both refers to "basic character
sets", which contains a null character which is defined to have all
bits sets to 0).

While the definition are in the end quite similar, I think that the C++
avoided direct reference to the ASCII table by choice (so that C++ is
not tied to this charset) and thus it can't use the name NUL character
to describe '\0'.

As a consequence, I was wrong when I spoke about a nul character, from
two point of view : first, it's not the C and C++ standard terminology,
and second, it doesn't even exist (but NUL does).

Sorry for the inconvenience.

-- Emmanuel Deloget, Artware

 

[eriwik]

On the other end, neither the C standard nor the C++ one relie on the
ASCII table to express characters (both refers to "basic character
sets", which contains a null character which is defined to have all
bits sets to 0).

While the definition are in the end quite similar, I think that the C++
avoided direct reference to the ASCII table by choice (so that C++ is
not tied to this charset) and thus it can't use the name NUL character
to describe '\0'.

As a consequence, I was wrong when I spoke about a nul character, from
two point of view : first, it's not the C and C++ standard terminology,
and second, it doesn't even exist (but NUL does).

In the latest Working Draft (don't know of the current standard) there
are two mentions of ASCII, both in footnotes. The first of those might
be relevant here:
"The glyphs for the members of the basic source character set are
intended to identify characters from the subset of ISO/IEC 10646 which
corresponds to the ASCII character set. However, because the mapping
from source file characters to the source character set (described in
translation phase 1) is specified as implementation-defined, an
implementation is required to document how the basic source characters
are represented in source files."