OpenEuphoria

Re: LCCWIN ver WATCOM, BORLAND and interpreter

• Posted by euman at bellsouth.net Oct 20, 2001
• 409 views

> 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