strlen cause SIGSEGV core if the parameter point to null
Using SUN studio 11 IDE in Solaris9 platform create a simple C app:
.....
char * pt=0;
printf( "%i", strlen(pt));
...
execute it wil lcause SIGSEGV core from strlen().
Does anybody explain this?
Here is definition for strlen() I got:
RETURN VALUE
The strlen() function shall return the length of s; no return value shall be reserved to indicate an error.
ERRORS
No errors are defined.
The strlen() function shall return the length of s; no return value shall be reserved to indicate an error.
[571 byte] By [
wyb2005] at [2007-11-26 10:37:10]
# 1
> Does anybody explain this?
Yep. See implementation of strlen() at http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/gen/strlen.c#43 (in fact, Solaris 10 has optimized implementation, but it is essentially identical to the C code above; take a look at http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/sparc/gen/strlen.s#6 6).
As you have noted, no errors are defined for strlen() function; it is not the function duty to check if the string passed is actually a null pointer or it points to an unallocated memory, or uninitialized memory. If you need this functionality from strlen(), you can easily replace libc.so`strlen() with your own version of strlen, just declare non-static strlen() in your executable or one of the libraries and it will be picked up by dynamic linker during symbol resolution process.
# 2
Trying to replace standard library functions other than the ones defined as replaceable (like malloc and free) is a Bad Idea.
1. You cannot be sure that the function will actually be replaced. Function strlen in particular might already be generated inline in exsiting code or libraries, and from that code your replacement function will not be called.
2. The actual implementation of a standard function might do things that other library functions depend on, and your replacement function can cause those ofther library functions to fail.
3. The function might co-exist in a single .o with other library functions that you link. You then wind up with two global versions fo the function, and your program won't link.
The C and Unix standards say that strlen must be passed a pointer to a null-termiinated string. A null pointer is not such a pointer, so your code cannot be expected to work.
If you want to be sure that your program will always work, you have several options
1. Test for a null pointer yourself before calling strlen when in doubt.
2. Write a funciton mystrlen that tests for null and calls strlen.
3. Don't use null string pointers. Use a pointer to an empty string instead.
Each of these approaches has advantages and disadvantages. Which of these (or some other option) is best depends on the design and details of your application.
# 4
Using 0@0 is not a portable solution, and in addiiton hides all null pointer errors. You can wind up with null pointer errors in the code that simply generate incorrect results with no other visible bad effects. That's nice if you are hired on an hourly basis to debug the code, but not so nice when you have customers complaining about applications not working.
Instead of treating crashes as an inconvenience to be suppressed, treat them as an opportunity to make your code more robust, preventing future program failures.
