Thread: Proofing existing functions

>char *result = (char *) malloc (250);
All well and good (sort of, but still correct). result now points to the start of a block of memory 250 bytes in size.

>for (result=str; *result; result++) {
Not okay. You just lost your memory by assigning str to result. You want something more like this:

Code:

char *strcap (char *str) {       /*capitalizes all the letters in an array*/

  char *result = malloc (250);
  char *p = result;

  while (*str != '\0')
    *p++ = (char)toupper(*str++);
  *p = '\0';

  return result;
}

>Prelude where would I be without you.
Without me you would be in the depths of segfault hell, forced to port VAX/VMS applications to MS-DOS while being whipped with hardcopy of the Windows 3.0 source code by Herbert Schildt.

>Why do you need the (char) in front of the toupper statement.
It silences a warning on my favorite compiler. toupper returns an integer and assigning an integer to a character could result in a loss of information, so the compiler is obliged to warn about it. The cast tells the compiler that I'm well aware of the potential danger.

>It silences a warning on my favorite compiler.
And which compiler would that be?

>would my method I described be adequete
You're thinking to hard about it. strncmp is nothing more than a loop terminating when n reaches 0 or the end of the string is found, and a test for equality in the body. Just remember to return -1, 0, or +1 accordingly.

>And which compiler would that be?
Visual C++ .NET. But only because my employers make me...yes, that's it.

Microsoft? Ewwwwwwwwwwwwwwwwwwwww.

You don't decrement n:

Code:

int strncmp (char *s, char *t, int n) { /*compares the two arrays*/

  char *p1, *p2;

  for (p1=s, p2=t; n--; p1++, p2++)
  {
    if (*p1 > *p2)
      return 1;
    if (*p1 < *p2)
      return -1;
    if (*p1 == '\0' || *p2 == '\0')
      break;
  }
  return 0;
}

Hello all,

I'm not sure if this helps, but I have written an strncmp() prototype before. It's kinda short and simple, and I believe it works:

Code:

int strncmp(const char *string1, const char *string2, size_t num) {
	int	char1, char2;

	do {
		char1 = *string1++;
		char2 = *string2++;

		if (!num--)
			return 0;
		
		if (char1 != char2)
			return char1 < char2 ? -1 : 1;
	} while (char1);
	
	return 0;
}

Code 1.1: strncmp() prototype example

Also, I'm not sure if you'd want to malloc() 250 bytes everytime you call on strcap() also assuming you already allocated memory for your string before calling on a function. I might be wrong though, but this implementation hasn't crashed on me since:

Code:

char *strcap (char *str) {
	char	*s = str;

	while (*s) {	// while it isnt 0
		*s = toupper(*s);
		s++;
	}

	return str;
}

Code 1.2: Converting whole string to uppercase

If I am wrong in my thinking and function(s), please let me know. I just try to stay away from using any allocation initialization when using a prominent function.


Hope this helps,
- Stack Overflow

>but this implementation hasn't crashed on me since
You've been lucky. If strcap is called with a string literal as the argument (like in pxleyes' driver) then you could very well have problems. You shouldn't attempt to modify string literals.

>I'm not sure if you'd want to malloc() 250 bytes everytime you call on strcap()
I agree that as it is the allocation isn't the best, and decentralizing allocation and release of memory from a single function tends to result in memory leaks. You can ignore the issue of forgetting to free the memory and simply do this:

Code:

char *strcap ( const char *str )
{
  char *rs = malloc ( strlen ( str ) + 1 );
  char *p;

  if ( rs == NULL )
    return NULL;
  for ( p = rs; ( *p = *str ) != '\0'; p++, str++ )
    ;

  return rs;
}

Past that you would need to force restrictions on the caller by requiring a buffer of the appropriate size be passed, or only modifiable strings be allowed. The former is awkward in this case and the latter is impossible to test for. Make your own conclusions.

>I just try to stay away from using any allocation initialization when using a prominent function.
It's best to take things on a case by case basis. Different situations will have different advantages and disadvantages. Strictly following a simple guideline of avoiding dynamic memory for prominent functions can get you into trouble just as easily as using dynamic memory poorly.

>How does that work? Decrementing n-- in the conditional spot of the for loop.
Work it out on paper, first test then decrement and see how the end result is n iterations of the loop.