Why is malloc'd char array not working but char p[256] is?

Inside a function, I create a char array which I pass to a library function that fills it with a value. I then pass this back to the caller. When I do it by creating an array with malloc (and then freeing it outside the function), it only fills the array with the first 3 characters. When i create it as a local array, it works (and simply warns me I'm passing a local array back out).

Code:

---


//This does NOT Work:
char* getStringWithMalloc(...elided...)
{
      char* data = ( char* ) malloc( 256 * sizeof( char ) );
      fillArray( data );
      return data;
}

//This DOES work:
char* getString(...elided...)
{
      char data[256];
      fillArray( data );
      return data;
}

int main(...)
{
      //Does not work, only grabs first three characters
      char* value = getDataWithMalloc(...);
      printf( value );
      free( value );

      //This DOES work
      printf( getDataWithMalloc(...) );
}

---

This is related to your other question with usb values, isn't it. My guess would be that fillarray is told the size of the array with sizeof...

--
Mats

Yeah, I thought that sizeof() would be the same for a malloc'd array and a char[] array.

Quote:

---

Originally Posted by 6tr6tr

Yeah, I thought that sizeof() would be the same for a malloc'd array and a char[] array.

---

hmm... but if you are passing the array to fillArray(), the array decays to a pointer to its first element, so there would be no difference... unless your example of fillArray() excluded the size argument.

Quote:

---

Originally Posted by 6tr6tr

Yeah, I thought that sizeof() would be the same for a malloc'd array and a char[] array.

---

It is not. Sizeof is resolved at compile time, and although the compiler may well understand the function malloc, it wouldn't understand if you actually want the size of the allocated memory or the size of the pointer. There are potentially non-standard functions that gives the size of the allocation, but you would be in an awkward position of dependancy on a particular compiler or C library if you start using them.

--
Mats

Code:

---

//This DOES work:
char* getString(...elided...)
{
      char data[256];
      fillArray( data );
      return data;
}

---

But of course you must know that returning a local variable like that is completely wrong, since the memory where that local variable resides is reused after the function returns and will eventually get overwritten with other stuff.

Quote:

---

Originally Posted by cpjust

Code:

---

//This DOES work:
char* getString(...elided...)
{
      char data[256];
      fillArray( data );
      return data;
}

---

But of course you must know that returning a local variable like that is completely wrong, since the memory where that local variable resides is reused after the function returns and will eventually get overwritten with other stuff.

---

As I pointed out in the third thread on the same subject by the same author - that's why having multiple threads is a bad thing.

--
Mats

Quote:

---

Originally Posted by matsp

As I pointed out in the third thread on the same subject by the same author - that's why having multiple threads is a bad thing.

--
Mats

---

I don't read all the posts - just the interesting ones, so that's why I didn't see it. :)

Please don't ever do that ...elided... thing. Whenever you do that, you haven't done enough of what you should be doing to solve the problem yourself.

If you haven't eliminated the effects those parts have on your problem then you need to do more work to eliminate those parts as a possible cause before posting. Once you've determined that it isn't related to the problem, then your simplest complete compileable example that you post shouldn't contain it since it is no longer relevant. If you determine that it is part of the problem then you'd be wasting your time and ours by leaving it out.

Usually it is part of the problem. People have a habbit of leaving the part out that they think isn't the problem. If where they thought the problem was, actually was where the problem was, then they would already know the solution.

Quote:

---

Originally Posted by cpjust

I don't read all the posts - just the interesting ones, so that's why I didn't see it. :)

---

Yes, and my point was that there shouldn't be three different threads discussing the exact same subject with slightly different titles and somewhat different content.

--
Mats