1. Bug in Safe.e discovered today
- Posted by Al Getz <Xaxo at aol.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
Hello there,
I've managed to uncover a bug in Safe.e today while working on
a program that used to allocate a struct incorrectly.
The problem occurs in the routine:
global function allocate_string(sequence s)
-- create a C-style null-terminated string in memory
atom mem
mem = allocate(length(s) + 1)
if mem then
poke(mem, s)
poke(mem+length(s), 0) -- Thanks to Aku
end if
return mem
end function
If the sequence s is null (s="") it causes a machine error to be generated
while trying to poke into memory.
The temporary workaround was this:
global function allocate_string(sequence s)
-- create a C-style null-terminated string in memory
atom mem
mem = allocate(length(s) + 1)
if mem and length(s)>0 then
poke(mem, s)
poke(mem+length(s), 0) -- Thanks to Aku
end if
return mem
end function
On the plus side, because there was a level of protection written
for 'c_func' too, after the above was implemented safe.e caught my
Win API call with the badly allocated struct. Very nice!
Thanks again to Matt for suggesting the use of Safe.e .
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
2. Re: Bug in Safe.e discovered today
- Posted by Robert Craig <rds at RapidEuphoria.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
Al Getz wrote:
> I've managed to uncover a bug in Safe.e today while working on
> a program that used to allocate a struct incorrectly.
>
>
> The problem occurs in the routine:
>
> global function allocate_string(sequence s)
> -- create a C-style null-terminated string in memory
> atom mem
>
> mem = allocate(length(s) + 1)
> if mem then
> poke(mem, s)
> poke(mem+length(s), 0) -- Thanks to Aku
> end if
> return mem
> end function
>
> If the sequence s is null (s="") it causes a machine error to be generated
> while trying to poke into memory.
>
> The temporary workaround was this:
>
> global function allocate_string(sequence s)
> -- create a C-style null-terminated string in memory
> atom mem
>
> mem = allocate(length(s) + 1)
> if mem and length(s)>0 then
> poke(mem, s)
> poke(mem+length(s), 0) -- Thanks to Aku
> end if
> return mem
> end function
>
>
> On the plus side, because there was a level of protection written
> for 'c_func' too, after the above was implemented safe.e caught my
> Win API call with the badly allocated struct. Very nice!
>
> Thanks again to Matt for suggesting the use of Safe.e .
That bug was fixed more than a year ago in 2.5 alpha.
Maybe it's time to upgrade?
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Bug in Safe.e discovered today
- Posted by Al Getz <Xaxo at aol.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
Robert Craig wrote:
>
> Al Getz wrote:
> > I've managed to uncover a bug in Safe.e today while working on
> > a program that used to allocate a struct incorrectly.
> >
> >
> > The problem occurs in the routine:
> >
> > global function allocate_string(sequence s)
> > -- create a C-style null-terminated string in memory
> > atom mem
> >
> > mem = allocate(length(s) + 1)
> > if mem then
> > poke(mem, s)
> > poke(mem+length(s), 0) -- Thanks to Aku
> > end if
> > return mem
> > end function
> >
> > If the sequence s is null (s="") it causes a machine error to be generated
> > while trying to poke into memory.
> >
> > The temporary workaround was this:
> >
> > global function allocate_string(sequence s)
> > -- create a C-style null-terminated string in memory
> > atom mem
> >
> > mem = allocate(length(s) + 1)
> > if mem and length(s)>0 then
> > poke(mem, s)
> > poke(mem+length(s), 0) -- Thanks to Aku
> > end if
> > return mem
> > end function
> >
> >
> > On the plus side, because there was a level of protection written
> > for 'c_func' too, after the above was implemented safe.e caught my
> > Win API call with the badly allocated struct. Very nice!
> >
> > Thanks again to Matt for suggesting the use of Safe.e .
>
> That bug was fixed more than a year ago in 2.5 alpha.
> Maybe it's time to upgrade?
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Rob:
I checked all my 2.5 files and couldnt find any change.
The files were all from around the end of 2004.
What was the 'official' change that fixed this?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
4. Re: Bug in Safe.e discovered today
- Posted by Robert Craig <rds at RapidEuphoria.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
Al Getz wrote:
> I checked all my 2.5 files and couldnt find any change.
> The files were all from around the end of 2004.
>
> What was the 'official' change that fixed this?
If you do a fc on safe.e between 2.4 and 2.5
you'll see that several lines have changed.
I think the relevant change was to add an
if-statement to test if len is 0
at the start of safe_address()
I'm not sure if that was the only relevant change.
function safe_address(atom start, integer len)
-- is it ok to read/write all addresses from start to start+len-1?
atom block_start, block_upper, upper
sequence block
if len = 0 then
return OK
end if
...
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Bug in Safe.e discovered today
- Posted by Al Getz <Xaxo at aol.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
Robert Craig wrote:
>
> Al Getz wrote:
> > I checked all my 2.5 files and couldnt find any change.
> > The files were all from around the end of 2004.
> >
> > What was the 'official' change that fixed this?
>
> If you do a fc on safe.e between 2.4 and 2.5
> you'll see that several lines have changed.
>
> I think the relevant change was to add an
> if-statement to test if len is 0
> at the start of safe_address()
> I'm not sure if that was the only relevant change.
>
> }}}
<eucode>
> function safe_address(atom start, integer len)
> -- is it ok to read/write all addresses from start to start+len-1?
> atom block_start, block_upper, upper
> sequence block
>
> if len = 0 then
> return OK
> end if
>
> ...
> </eucode>
{{{
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Hi again Rob,
Oh ok that's great...thanks. I could probably use the file then with 2.4 or
make the changes in 2.4's file too then.
BTW the -safe- level wrapping for 'c_func' was a very good idea...
that caught the error right away. I didnt have to wait for the
program to try to peek or poke anything.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
