Mail Archives: djgpp/1995/10/26/04:17:44
On Tue, 24 Oct 1995, Keren Yaron wrote:
> Is it reasonable that sprintf allocates 33K?
>
> The test program is:
>
> main() {
> char s[100];
>
> cout<<_go32_dpmi_remaining_physical_memory()<<endl;
> sprintf(s,"%10.3f",-0.01);
> cout<<s<<endl;
> cout<<_go32_dpmi_remaining_physical_memory()<<endl;
>
> return 0;
> }
There is more to this little program than just sprintf(). How about
`cout', don't those little critters gobble memory? Anyway, the following
program compiled in C shows that:
1) The first sprintf() eats up 4KB (suspiciously close to the
size of transfer buffer), next sprintf()'s don't add anything to this.
2) The first fputs() eats up another 4KB, next fputs()'s again
don't add anything.
(Btw, in v2.0, the same program reports NO MEMORY USED at all, which is
what I would expect, since the transfer buffer is already allocated when
the program starts running, and no new FILE descriptors are created.)
I suggest that you try to separate sprintf() from cout, and I think
you'll see that only the 1st sprintf() allocates 4KB, the rest probably
comes from cout and all the temporaries its creates along the way.
#include <stdio.h>
#include <dpmi.h>
int
main(void)
{
unsigned long mem1, mem2, mem3, mem4, mem5;
char buf1[80], buf2[80], buf3[80], buf4[80], buf5[80];
mem1 = _go32_dpmi_remaining_physical_memory();
sprintf(buf1, "1: %lu", mem1);
mem2 = _go32_dpmi_remaining_physical_memory();
sprintf(buf2, " 2: %lu", mem2);
mem3 = _go32_dpmi_remaining_physical_memory();
sprintf(buf3, " 3: %lu", mem3);
fputs(buf1, stdout);
mem4 = _go32_dpmi_remaining_physical_memory();
sprintf(buf4, " 4: %lu", mem4);
fputs(buf2, stdout);
mem5 = _go32_dpmi_remaining_physical_memory();
sprintf(buf5, " 5: %lu\n", mem5);
fputs(buf3, stdout);
fputs(buf4, stdout);
fputs(buf5, stdout);
return 0;
}
- Raw text -