OpenEuphoria

Re: realloc() failing under DOS (why it does'nt ...)

• Posted by pseudonomus at yahoo.com Nov 08, 2001
• 440 views

Thanks for clearing that up, Robert!

Still, an example of some code of mine in C that fails
confuses me.

Can you tell me why it fails, and why your Eu source
does not? As I see it the Eu source is kind of
simmilliar to my code in appending or concatenating as
you say it calls standard malloc() routines only ...

<Code!>

#include <stdio.h>
#include <stdlib.h>

void *Malloc(int size)
{
  void *ret;
  if((ret = malloc(size)) == NULL)
  {
     puts("This program ran out of memory...");
     exit(1);
  }
return ret;
}

void *Realloc(void *mem,int size)
{
  void *ret;
  if((ret = realloc(mem,size)) == NULL)
  {
     puts("This program ran out of memory...");
     exit(1);
  }
return ret;
}


main()
{
    char *s;
    int i;
    s = (char*)Malloc(1);
    
    puts("Started ...");

    i = 1;
    while(i != 6000000) /* 6 megs */
    {  i++;
       s = (char*)Realloc(s,i);
       s[i-1] = 'X';
       s[i] = 0; /* EOS */
    }
    puts(s); /* "XXXXXXXXXXX ... " */
    free(s);
}

</Code!>

As you will notice when compiling the above code with
DJGPP or Watcom, not only is it extremely slow on
these compiler platforms, but it might not concatenate
at all, displaying 'This program ran out of memory...'
.
It might even fail with Borland or LCC, or just be way
too slow...

Yet this code in Eu:

sequence s
s = "";
for i = 1 to 6000000 do
   s &= "X"
end for
puts(s)

works perfectly fast, and does not crash Euphoria.

Yet all it (kinda) does as you say is what above C
code does.

Sure Euphoria might allocate a couple of extra bytes
after each reallocation so it will be a few percent
faster, but surely this is not the reason why it does
not fail and 'standard' C code does.

Will we face this problem maybe when compiling the
Euphoria source?
Is it a fluke that Euphoria does not fail when
appending?

Or am I compiling above source with wrong compiler
directives that will make even Euphoria fail when
compiled like that?

Surely there must be a reason why Euphoria source can
call realloc() and malloc() so many times, millions of
times, and still not run out of memory and still be
fast (as if it has a magical, safer, faster
malloc()/realloc() implementation, which you say is
not the case)...

Do note that I have only 16 megs of ram,
but enough virtual memory installed!
(about 20 gigs!!)


--- Robert Craig <rds at RapidEuphoria.com> wrote:
> 
> pseudonomus writes:
> > How does Euphoria solve the problem with
> > realloc()/malloc() failing under dos?
> 
> I did find one rare case where realloc fails 
> (or at least doesn't behave as advertised) with
> Watcom,
> but it was possible to work around this case.
> 
> > We (future Eu source hackers!) must know because
> if
> > the Euphoria source does not use standard
> > implementations of malloc(), realloc(), etc., then
> it
> > will not be portable to other plaftorms (such as
> > FreeBSD, OS/2, MacOS, etc.) that easilly.
> 
> Euphoria calls the standard malloc() etc., so
> it should be possible to port to other platforms.
> 
> > And, when will the source be released anyways?
> 
> The 2.3 alpha-test release, including source for 
> the interpreter, should be available in about 2
> weeks.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com
> 
>
> 
> 
>
>