BL> but do it with strings and you *have* to pass addresses, and
 BL> you *have* to allocate space.

 RM> You have to pass addresses, *or* you have to allocate space

  If you can pass an address, then you have *already* allocated space.

 RM> To pass a string to a function for the function to modify, try
 RM> this (simplified)
 RM> 
 RM> myfunc( char *s)
 RM> {
 RM> int i;
 RM> char *p;
 RM> i = strlen(s);
 RM> p = malloc(i);
 RM> strcpy(p,s);
 RM> /* do stuff to p */
 RM> free(p);
 RM> }

  Yair! That took me terrible pain (and many reboots) to work out. I
like the free(p) on the end. It answers my other concern.

  But I think you are wrong. You don't need malloc() to get space for
p if you use strcpy(). s is defined as space outside and you pass it
to the function as a pointer. strcpy() then makes space for p (a
pointer in strcpy), using the size of s which is a constant.

  But what happens, is that the space for p uses the same address if
you run myfunc() a second time without the malloc(). If you run
malloc() first, you get a brand-new address (unless you have freed it,
presumably).  

  I think. I've been buggering around trying to get it straight, and
it's possible that I'm still stuffed up somehwat (but not as much as
yesterday).

 BL> If the parameter is a large object how can you pass it unless
 BL> you use the address? Even when you *think* you're not, C is
 BL> doing it automatically.

 RM> sales1() does pass a copy of the entire contents of the
 RM> structure, not the address.

  I thik we are at cross purposes. It actually passes a pointer that
points to the new memory allocation.

 RM> Paul Markham wrote a pkt sorter called Sortpkt that does
 RM> massive on-the-fly memory grabs.

  That's what I do with pkt2qwk, except that in VB I do massive 32K
memory grabs and use name-arrays and the occasional sctruct. It works 
very well, and now I am doing the same thing in C, to see the advantages 
and disadvantages. So far, I haven't found any advantages (rofl), but 
I'm learning a lot more than I wanted to learn about memory and elves.

  My VB pkt2qwk is a 600-line program, and I've been a fortnight
trying to read the data file! It took 28 lines in VB, and I haven't
got onto the hard part yet, where I actually convert pkt to qwk.

 RM> I use it between Bink and Ppoint to get the messages into
 RM> subject and date order, and it's not unusual for Sortpkt to
 RM> grab 1.5M of ram; it reads multiple pkt files all into ram,
 RM> seeks out the message headers, sorts an array of headers, and
 RM> writes the big ram block msg by msg into a sorted file. The dos
 RM> version runs under the dos extender Dos4GW that comes with the
 RM> Symantec compiler. Source is available. Paul Rightwing may
 RM> still have the archive somewhere.

  I had a look at it when I was writing VB2QWK, but I couldn't make
head nor tail of the C code (another problem with C, BTW), but I have
hopes that it will suddenly become clear in a blinding cognition such
as St Paul experienced on the Road to Damascus. Failing that, I can
use Pascal  :-)

  I actually think that I'm getting somewhere... if I can only work
out what char *p[64]; means.

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

---