1. realloc() failing under DOS (why it does'nt ...)
This one goes out to Robert.
As the source to the interpreter and translator will
soon be released, there is one thing that boggles my
mind.
How does Euphoria solve the problem with
realloc()/malloc() failing under dos?
As you might know, realloc(), malloc() and calloc()
for Watcom DOS32 and DJGPP fail when allocating a
couple of megs, even if it's just a fraction of the
amount you have physycally installed. Plus, realloc()
for DJGPP is extremely slow, yet appending to
sequences seems to be quite fast.
append() calls realloc(), yet it doesn't fail when
called a lot, why?
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.
And, when will the source be released anyways?
2. Re: realloc() failing under DOS (why it does'nt ...)
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
3. Re: realloc() failing under DOS (why it does'nt ...)
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
>
>
>
>
>
>
4. Re: realloc() failing under DOS (why it does'nt ...)
pseudonomus writes:
> s = (char*)Realloc(s, i);
> s[i-1] = 'X';
> s[i] = 0; /* EOS */
In C, if s is a pointer to i bytes, then s[i] is *not* a valid element.
The subscripts run from 0 to i-1. You are writing a byte beyond
the allocated space. Sometimes this won't matter. Other times
it will lead to disaster.
> Yet this code in Eu:
> ...
> works perfectly fast, and does not crash Euphoria.
> ...
> Is it a fluke that Euphoria does not fail when
> appending?
I've been pulling my hair out for many years, working
with malloc, realloc and friends. I think I have most of the
bugs out now. Buy the source in 2 weeks and learn all
the tricks of the trade. 
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: realloc() failing under DOS (why it does'nt ...)
- Posted by euman at bellsouth.net
Nov 08, 2001
> Rob Craig wrote:
> I've been pulling my hair out for many years,
I always pictured you as a bald man Robert..... hehehe 
6. Re: realloc() failing under DOS (why it does'nt ...)
--- Robert Craig <rds at RapidEuphoria.com> wrote:
>
> pseudonomus writes:
> > s = (char*)Realloc(s, i);
> > s[i-1] = 'X';
> > s[i] = 0; /* EOS */
>
> In C, if s is a pointer to i bytes, then s[i] is
> *not* a valid element.
> The subscripts run from 0 to i-1. You are writing a
> byte beyond
> the allocated space. Sometimes this won't matter.
> Other times
> it will lead to disaster.
Arrghh!
That's a syntax error :p
I posted the C code in question as a quick explenation
of my point, yet I introduced a syntax error in the
proccess.
The code I've being having trouble with is the
following;
char *characterWeld(char *dest,char source)
{
int dl = strlen(dest);
dest = (char*)realloc(dest,dl+2);
dest[dl] = source;
dest[dl+1] = 0;
return dest;
}
main()
{
int i = 6000000;
char *s = (char*)malloc(1);
while(i--)
s = characterWeld(s,'X'); /* Fails */
}
Above code is correct for a change :p
But ...
> Buy the source in 2 weeks and learn
> all
> the tricks of the trade.
I'll do just that.
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
