TIP: Click on subject to list as thread! ANSI
echo: aust_c_here
to: David Nugent
from: Frank Adam
date: 1996-06-21 08:11:00
subject: Memory Blocks snuffed ?

G'Day David,
 
-=> Quoting David Nugent to Frank Adam <=-

 > Tested in TC2 and BC4, worked correctly in both.
 > This function will return the size of the memory block held by a pointer.
 > It will do a realloc too, according to parameter 2 and 3.

 DN> same block size?  This sounds too much like a search for a 
 DN> square wheel to me.
Oh, but it enhances the mind :)
Btw, i didn't know that realloc will do nothing if the same size is sent 
to it, but i was not concerned about that.
I was more concerned about it reducing the allocated size to a smaller 
size, where other parts of the program may not be aware of it.
 
 DN> depends on which platform you're compiling for (did you try 
 DN> this with a Windows program, for example?).
No, not yet. Me and windows programs don't hit it off too well.

 DN> I'm still not sure what you're attempting to achieve that 
 DN> realloc() does not do already.
Stand alone functions.
If a function is meant to alter the passed variable in a way that it will 
increase the size , it has two choices. 

1. Assume. (the caller properly allocated the required memory).
2. Re-allocate. (the size of the variable to the required length).

case 1 is preferred, but at times the caller does not know the nec. size 
in advance.
case 2 can truncate the original size of the variable without the callers
knowledge.

I'm trying to avoid both case 1 and 2 without using a malloc function,
like the one in your last message. Don't get me wrong it's not the 
function, i'm just trying for a different way.

It seems a waste to duplicate a table, which would normally be somewhere
in the environment already, even though i do realize, this would be very 
compiler specific, to say the least.
This will come as a shock, but i'm not a professional programmer, so 
any time i spend on (perhaps stupid) things like this is mainly for fun,
and in my spare time, so as long as i'm not losing money...:) 
Never the less, every environment has to keep track of the memory in some
way, it's a matter of finding a common dominator, or not finding it. 
When i first fired up my trusty VZ300, P166s seemed impossible too :-)
                                        
  L8r Frank (fadam{at}ozemail.com.au).
                                   
___ Blue Wave/DOS v2.21

--- Maximus 3.01
* Origin: The Software Parlour (3:635/544)
SEEN-BY: 50/99 620/243 623/630 632/349 635/503 544 727 711/401 409 410 413
SEEN-BY: 711/430 808 809 932 934 712/515 713/888 714/906 800/1
@PATH: 635/544 50/99 711/808 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.