BL> . or just pass (n) instead of (&n) and write the data to that
 BL> location?

 PE> I told you, n is pointing to a random location. Writing to a
 PE> random location causes random things to become corrupted. 

  I know that. You would have to make n point to real memory you would
then write to. Instead of declaring the array in the function you
would declare it globally.

 PE> It's not an extra step, it's the minimum you can do in that
 PE> circumstance. If you were to declare n as char[500], you could
 PE> do a strcpy into that. A strcpy() is far more expensive than
 PE> setting a pointer. 

  You misunderstand. I look at the process rather simply. Memory is
real and that's where the data is. Pointers are only 4 bytes and data
can be big, so in that case it's easier to move pointers. It's just a
question of where you have the data. If you pass a pointer, you may as
well pass the pointer to the data as a pointer to another pointer (to
the data).

 BL> Does a static array persist after the function has been called?

 PE> Yes.

  How strange. You call a function, close the function, and the data
stays... sort of like global data on demand. How do you get rid of it?

 BL> what happens if you call it again? 

 PE> I don't know what you mean.

 BL> Does it make a new set of data in memory? 

  I'm used to writing FAXs to China so I always say everything twice
for the hard of hearing and thinking.

 PE> No. That data is stored in a fixed position, set at compile
 PE> time, and built into the executable. That's the whole point of
 PE> static.

  Why not make it global? That would obviate the need to pass pointers
to pointers and save a step.

 BL> How does it know one "names" from the next one?

 PE> There's only the one. In that function, anyway.

  It's memory that stays clogging up the system after the use for it
has gone, but can only be accessed by the function you're no longer
using. Great idea. Has C got many like that? Why not just make it
global?

Regards,
Bob
     
___ Blue Wave/QWK v2.12
@EOT:

---