| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.