Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Strlen and \0 terminator

Status
Not open for further replies.

BTCMan

Programmer
Jun 17, 2005
21
BR
Hi,

I would like your expertise in order to protect my code for strings without the \0 terminator (in case of memory corruption). Currently the code is failing because when it invokes strlen for a string with trash in it it never finds the \0 terminator then returns the size of the datatype (per example: int 8 string var will return 256. Can anyone give some clue on how can I ensure that I will not have this problem (per example: if the string is corrupted return error instead go ahead with the strlen). Also I would like to differentiate the trash string with \0 from a sane string with \0 in the END (but I think this is not feasible right?)
Thanks

BTCMan
 
> in case of memory corruption
Erm, if you're getting memory corruption, the lack of a \0 is the least of your problems.
Absolutely anything else could be happening as well, including crashing before you get anywhere near a strlen call.

Fixing the bugs in the code is the only way forward IMO.

> but I think this is not feasible right?)
No it isn't.

It's easy to write your own strnlen() function which returns after 'n' characters or the \0, but that isn't going to solve any underlying problems.

--
 
Hi Salem,

the mem corruption cannot be avoided/detected in this scenario and what I want to do is to protect other portion of code with this mechanism. I am trying to use "strstr" command to look for a "\0" so if it does not find any then the strlen should never be executed.


BTCMan
 
Like I said, as soon as memory has been corrupted, all bets are off.

Even if you get past this problem, there's no guarantee of success later on.

> the mem corruption cannot be avoided/detected in this scenario
Please explain this in detail.

If you're using gets() to read input, then just use fgets() and all your buffer overrun problems go away.


--
 
Code:
int strnlen( const char* str, int maxlen )
{
   int i;
   int n = 0

   for ( i = 0; i < maxlen; ++i, ++n )
   {
      if ( str[i] == '\0' )
      {
         return n;
      }
   }

   /* NULL terminator was not found before maxlen, return -1 to indicate error. */
   return -1;
}
But I'd take Salems advice about fixing your memory corruption problems first.
 
Explanation for "> the mem corruption cannot be avoided/detected in this scenario":
- There is a 3rd party sw compononent that is sending messages to the code portion which I've mentioned that is doing the strlen. The code for the 3rd party sw compononent cannot be accessed so the assumption is that trash can be inside the message so let's protect the other portion of the code...(in this case let's avoid run a strlen in a string without null terminator)
 
> There is a 3rd party sw compononent that is sending messages to the code portion...
So is there a way for you to tell it
- store the data in this buffer
- the buffer is this big.

Unless you can either tell this component the size of the buffer its allowed to use, or some prior agreement in the interface specification as to the maximum buffer size, there is nothing you can really do except give it the largest buffer you can possibly manage and hope for the best (this isn't a good idea BTW).

Just look at the interface for fgets() for a prime example of communicating the buffer size.

Furthermore, things which can return arbitrary data usually have the capability of returning some kind of count of the actual amount of data in the buffer, so you don't have to resort to dubious strlen() approaches. An example of this kind of interface is typified by fread().

--
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top