This patch does the following cleanups for Documentation/vm/slabinfo.c:
	- Fix two memory leaks;

	- Constify some char pointers;

	- Use snprintf instead of sprintf in case of buffer overflow;

	- Fix some indentations;

	- Other little improvements.
And it is against 2.6.23-rc9.
CC: Christoph Lameter <clameter@sgi.com>

Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
---

 Documentation/vm/slabinfo.c |   27 +++++++++++++++------------

 1 file changed, 15 insertions(+), 12 deletions(-)
Index: linux-2.6.23-rc9/Documentation/vm/slabinfo.c

===================================================================

--- linux-2.6.23-rc9.orig/Documentation/vm/slabinfo.c

+++ linux-2.6.23-rc9/Documentation/vm/slabinfo.c

@@ -11,6 +11,7 @@

 #include <stdlib.h>

 #include <sys/types.h>

 #include <dirent.h>

+#include <strings.h>

 #include <string.h>

 #include <unistd.h>

 #include <stdarg.h>

@@ -84,7 +85,7 @@ void fatal(const char *x, ...)

 	va_start(ap, x);

 	vfprintf(stderr, x, ap);

 	va_end(ap);

-	exit(1);

+	exit(EXIT_FAILURE);

 }
 void usage(void)

@@ -119,14 +120,14 @@ void usage(void)

 	);

 }
-unsigned long read_obj(char *name)

+unsigned long read_obj(const char *name)

 {

 	FILE *f = fopen(name, "r");
 	if (!f)

 		buffer[0] = 0;

 	else {

-		if (!fgets(buffer,sizeof(buffer), f))

+		if (!fgets(buffer, sizeof(buffer), f))

 			buffer[0] = 0;

 		fclose(f);

 		if (buffer[strlen(buffer)] == '\n')

@@ -139,7 +140,7 @@ unsigned long read_obj(char *name)

 /*

  * Get the contents of an attribute

  */

-unsigned long get_obj(char *name)

+unsigned long get_obj(const char *name)

 {

 	if (!read_obj(name))

 		return 0;

@@ -147,7 +148,7 @@ unsigned long get_obj(char *name)

 	return atol(buffer);

 }
-unsigned long get_obj_and_str(char *name, char **x)

+unsigned long get_obj_and_str(const char *name, char **x)

 {

 	unsigned long result = 0;

 	char *p;

@@ -166,12 +167,12 @@ unsigned long get_obj_and_str(char *nam...
[ message continues ]

For user space code? Memory will be released as soon as the program 
Acked-by: Christoph Lameter <clameter@sgi.com>
-

Yes, it's of course in user space. But there really exists memory leaks,

since strdup(3) uses malloc(3) to allocate memory for new string, we

should use free(3) to free the memory, or this memory will be lost.
Regards. ;)
WANG Cong
-