Trimming Strings

[shiju]

I wrote two functions one for removing space from beginning and one from the end.

Its compiled and working as I expected.

When I am Running Splint on it.It is showing number of warnings.
I am not getting this warnings.

#include <stdio.h>
#include <string.h>
char * ltrim(char * str){
	int i;
	for(i=0;str[i] == ' ';i++);
	return &str[i];
}

char * rtrim(char * str){
	int i;
	for(i=strlen(str)-1;str[i] == ' ';i--);
	str[++i]='\0';
	return str;
}

int main()
{
	printf("-|%s|-",ltrim(rtrim("            Hello World             ")));
	return 0;
}

Split Output

Splint 3.0.1.6 --- 11 Feb 2002

shiju.c: (in function ltrim)
shiju.c(6,9): Immediate address &str[] returned as implicitly only: &str[i]
An immediate address (result of & operator) is transferred inconsistently.
(Use -immediatetrans to inhibit warning)
shiju.c: (in function rtrim)
shiju.c(13,9): Implicitly temp storage str returned as implicitly only: str
Temp storage (associated with a formal parameter) is transferred to a
non-temporary reference. The storage may be released or new aliases created.
(Use -temptrans to inhibit warning)
shiju.c: (in function main)
shiju.c(18,24): New fresh storage (type char *) passed as implicitly temp (not
released): rtrim(" Hello World ")
A memory leak has been detected. Storage allocated locally is not released
before the last reference to it is lost. (Use -mustfreefresh to inhibit
warning)
shiju.c(18,2): Return value (type int) ignored: printf("-|%s|-",...
Result returned by function call is not used. If this is intended, can cast
result to (void) to eliminate message. (Use -retvalint to inhibit warning)
shiju.c(3,8): Function exported but not used outside shiju: ltrim
A declaration is exported, but not used outside this module. Declaration can
use static qualifier. (Use -exportlocal to inhibit warning)
shiju.c(7,1): Definition of ltrim
shiju.c(9,8): Function exported but not used outside shiju: rtrim
shiju.c(14,1): Definition of rtrim

Finished checking --- 6 code warnings

[Prelude]

Splint is overly pedantic, all of those warnings can pretty much be ignored. Of course, it's always a good idea to try and figure out why they are there so that you know why they can be ignored.

>str[++i]='\0';
This will bite you eventually. The argument to rtrim is a string literal, which may reside in read-only memory. If you are able to modify a string literal, then you need to realize that such behavior is not portable. String literals should be treated as immutable.

[shiju]

>This will bite you eventually. The argument to rtrim is a string literal, which may reside in read-only memory. If you are able to modify a string literal, then you need to realize that such behavior is not portable. String literals should be treated as immutable.

Sorry I didn't understood why is it read-only.I think if you want it to be read-only you have to declare it with const keyword

[Prelude]

>I think if you want it to be read-only you have to declare it with const keyword
This is what you do for your own variables, but even then they aren't truly read-only.

>Sorry I didn't understood why is it read-only.
To give the implementation freedom in optimization. The short answer is that string literals are not required to be modifiable because the standard says so. It's a common extension though, so your compiler might support it. But be aware that your code isn't portable.

[shiju]

Thanks Prelude for your reply.

It will be great help if you throw some lights on memory leak. I have seen this many times while running splint, but I don't know what exactly it means.

[Prelude]

>It will be great help if you throw some lights on memory leak.
Put simply, a memory leak is when you allocate memory and don't release it. For long running programs, eventually you will run out of memory. This is a contrived memory leak:

#include <stdlib.h>

int main ( void )
{
  malloc ( 1000000 );

  return 0;
}

A reference to the memory is not saved, therefore free cannot be called on it, so there is no way to release it without relying on the calling process, which may or may not release all memory allocated to your program. Here is a more subtle and realistic memory leak (names changed to protect the guilty):

...
p = malloc(size * sizeof(*p));
...
/* Recalculate size */
...
p = realloc(p, size * sizeof(*p));

If realloc fails (a reasonable assumption in the program that this code was used), it returns NULL. NULL is then immediately assigned to p, and any reference to the memory that p pointed to before is lost. There is no way to access the memory to release it, so you have a leak.

[shiju]

Thanks once again