1. LCCWIN ver WATCOM, BORLAND and interpreter
- Posted by euman at bellsouth.net
Oct 20, 2001
Look at the code below,
iChild = allocate_string2(subdirs[j][D_LONGNAME])
poke4( tvstruct + TVINSERTSTRUCTITEM_pszText,iChild)
poke4( tvstruct + TVINSERTSTRUCTITEM_iImage,6)
poke4( tvstruct + TVINSERTSTRUCTITEM_iSelectedImage,6)
iChild = c_func(SendMessage,{TreeView1,TVM_INSERTITEM, 0, tvstruct})
free(iChild)
There is a bug in this code but only LCCWIN complained about it.....
and I didnt catch it rigt off until I used trace and re-compiled.
to correct the bug, change the SendMessage to junk
junk = c_func(SendMessage,{TreeView1,TVM_INSERTITEM, 0, tvstruct})
Now you are actually free'ing the right address for iChild
Why is it that Borland and the interpreter didnt catch this?
Makes me wonder what other little things might go un-noticed,
does anyone have a list of thing that they would check for?
Euman
euman at bellsouth.net
2. Re: LCCWIN ver WATCOM, BORLAND and interpreter
Hi Euman,
from the point of view of a compiler, it is not actually a bug. This is
because a compiler doesn't know what the variables and function mean. It
doesn't know what your intentions are.
For example, even if the compiler did know that "allocate_string2" takes
some memory from the system and allows your program exclusive access to it
and that this would normally be returned at some point by your code, the
compiler doesn't know that you intend to return that specific bit of memory
to the system. Just because you use a free() function later on, doesn't
absolutely make it necessary that you were intending to return the memory.
It might be required for any number of reasons and could be kept until the
program ends. Also, there is no way that the compiler would know that a call
to SendMessage using those specific parameters does not return some
allocated memory that you just happened not to need (thus you free()'ed it
immediately).
Because Euphoria has a simple 'type' system, it makes it hard for any
compiler (or Euphoria itself) to know what you were intending.
In 'C' one might have declared iChild as ...
char *iChild;
and the declaration for allocate_string2 would most likely have been
something like ...
char *allocate_string2(char *s);
thus when you use it in your code, the data type declarations match and the
compiler can guess tat you know what you are doing. If the sendMessage() had
been declared as ...
unsigned long sendMessage( ... );
then by assign its return value to iChild would have told the compiler that
you were attempting to assign an unsigned long value to something that is
supposed to hold a pointer to a character. Thus a data type mismatch could
have been detected and reported on.
Its a tough call for the Euphoria translator to guess the correct data type
that you intend for the Euphoria variables. Maybe this is the area that
needs more thought etc...
---
Derek
----- Original Message -----
From: <euman at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Sent: Sunday, October 21, 2001 8:09 AM
Subject: LCCWIN ver WATCOM, BORLAND and interpreter
>
> Look at the code below,
>
> iChild = allocate_string2(subdirs[j][D_LONGNAME])
> poke4( tvstruct + TVINSERTSTRUCTITEM_pszText,iChild)
> poke4( tvstruct + TVINSERTSTRUCTITEM_iImage,6)
> poke4( tvstruct + TVINSERTSTRUCTITEM_iSelectedImage,6)
> iChild = c_func(SendMessage,{TreeView1,TVM_INSERTITEM, 0, tvstruct})
> free(iChild)
>
> There is a bug in this code but only LCCWIN complained about it.....
> and I didnt catch it rigt off until I used trace and re-compiled.
>
> to correct the bug, change the SendMessage to junk
>
> junk = c_func(SendMessage,{TreeView1,TVM_INSERTITEM, 0, tvstruct})
>
> Now you are actually free'ing the right address for iChild
>
> Why is it that Borland and the interpreter didnt catch this?
>
> Makes me wonder what other little things might go un-noticed,
> does anyone have a list of thing that they would check for?
>
> Euman
> euman at bellsouth.net
>
>
>
3. Re: LCCWIN ver WATCOM, BORLAND and interpreter
Euman writes:
> ...Now you are actually free'ing the right address for iChild
>
> Why is it that Borland and the interpreter didnt catch this?
Euphoria's free() calls C's free().
Euphoria's allocate() calls C's malloc().
Each C compiler implements malloc() and free() differently.
I believe Watcom's free() just sets a bit saying "this block is free".
Joining together of adjacent free blocks is done later when malloc()
searches for a free block. So the crash may come much later
in your program, if at all, and for no apparent reason.
Other compilers do the joining together part immediately,
during the free() itself. This makes it more likely that a crash
will occur right away.
If you are using only allocate() and free(),
euphoria\include\safe.e can sometimes
be used to catch the case where you free an address
that you didn't allocate.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: LCCWIN ver WATCOM, BORLAND and interpreter
- Posted by euman at bellsouth.net
Oct 20, 2001
> Hi Euman,
> from the point of view of a compiler, it is not actually a bug. This is
> because a compiler doesn't know what the variables and function mean. It
> doesn't know what your intentions are.
This would imply that LCC is rather intuitive when it comes to the windows API.
This too could explain why LCC compiled programs are generally 1/3 the size
of a Borland compile program.
My being careless/reckless with the use of descripts has to be retaught.
In the program the example I posted came from, I was supposed to have iChild
allocated and the return from the sendMessage = hChild so it really is like
finding a needle in a hay stack when one letter has got you.
>
> For example, even if the compiler did know that "allocate_string2" takes
> some memory from the system and allows your program exclusive access to it
> and that this would normally be returned at some point by your code, the
> compiler doesn't know that you intend to return that specific bit of memory
> to the system. Just because you use a free() function later on, doesn't
> absolutely make it necessary that you were intending to return the memory.
> It might be required for any number of reasons and could be kept until the
> program ends. Also, there is no way that the compiler would know that a call
> to SendMessage using those specific parameters does not return some
> allocated memory that you just happened not to need (thus you free()'ed it
> immediately).
>
> Because Euphoria has a simple 'type' system, it makes it hard for any
> compiler (or Euphoria itself) to know what you were intending.
>
> In 'C' one might have declared iChild as ...
>
> char *iChild;
>
> and the declaration for allocate_string2 would most likely have been
> something like ...
>
> char *allocate_string2(char *s);
>
> thus when you use it in your code, the data type declarations match and the
> compiler can guess tat you know what you are doing. If the sendMessage() had
> been declared as ...
>
> unsigned long sendMessage( ... );
>
> then by assign its return value to iChild would have told the compiler that
> you were attempting to assign an unsigned long value to something that is
> supposed to hold a pointer to a character. Thus a data type mismatch could
> have been detected and reported on.
>
> Its a tough call for the Euphoria translator to guess the correct data type
> that you intend for the Euphoria variables. Maybe this is the area that
> needs more thought etc...
>
Thanks Derek,
> ---
> Derek
5. Re: LCCWIN ver WATCOM, BORLAND and interpreter
- Posted by euman at bellsouth.net
Oct 20, 2001
> it didn't catch it because it's perfectly legal
True, I dont dispute this. I do think and was hinting that maybe free( ) should
have
a check associated that would send a red flag up telling you about pre-existing
allocated adresses with the same name.
Euman
euman at bellsouth.net
6. Re: LCCWIN ver WATCOM, BORLAND and interpreter
- Posted by euman at bellsouth.net
Oct 20, 2001
Look at that, now this is worded wrong too.........> I need a break.
I must be thinking to hard o,r not at all.
Most likely it's the ladder part.
Euman
euman at bellsouth.net
> > it didn't catch it because it's perfectly legal
>
> True, I dont dispute this. I do think and was hinting that maybe free( )
> should have
> a check associated that would send a red flag up telling you about
> pre-existing
> allocated adresses with the same name.
>
> Euman
> euman at bellsouth.net
