OpenEuphoria

RE: Invaid argument type in dll.e

• Posted by Andy Serpa <ac at onehorseshy.com> Oct 07, 2003
• 409 views

Just a note:

There are a number of wrappers for external .dll libraries (zlib, 
sqlite, etc.) in the archives that should (now) be using cdecl 
declarations instead of stdcall (add "+" before the function name in the 
declaration).  They happen to work with the interpreter because of a 
quirk in Watcom, but will crash if translated to C.

So when making a wrapper, check to see what the proper calling 
convention is...



Brian Broker wrote:
> 
> 
> Hi Chris,
> 
> The bottom line is, the C routine definitions should never have been 
> declared with NULL's or 0's.  The definition's need to be fixed... This 
> shouldn't be too difficult but perhaps a bit time consuming.  Or you 
> could wrap define_c_func/proc to check for NULL parameters but then you 
> still need to replace occurrences of define_c_func/proc to whatever your 
> 
> wrapper name is.
> 
> Personally, I'd just fix the definitions and maybe re-release the fixed 
> code to the archives.
> 
> -- Brian
> 
> Chris Burch wrote:
> > Hi
> > 
> > I have a headache.
> > 
> > After purchasing eu2.4, I find that a lot of the downloaded programs are 
> > 
> > 
> > broken, particularly directe and exotica.
> > 
> > The problem lies in dll.e, particularly :-
> > 
> > global function define_c_func(object lib, object routine_name, sequence 
> > arg_sizes, atom return_type)
> > -- define a C function (or machine code routine)
> >     
> >     return machine_func(M_DEFINE_C, {lib, routine_name, arg_sizes, 
> > return_type})
> > end function
> > 
> > returns invalid argument type. (usually line 53) This didn't happen in 
> > eu2.3.
> > 
> > The reason (gathered from previous postings) - and correct me if I'm 
> > wrong, 
> > is that some programs pass NULL, and not {}, which is now interpreted in 
> > 
> > eu2.4 
> > differently.
> > 
> > Having traced thru (in exotica) various files, eg emain.ew, 
> > ewin32_api.ew, 
> > and replace various NULLs with {} the errors are changing places, so 
> > it's 
> > beginning to work.
> > 
> > However, other solutions could be
> > 
> > 1. Rewrite the eu sorce code to accomodate these different types passed 
> > to 
> > the interpreter - so that the error is not returned.
> > 
> > 2. Check the type passed to the define_c_func, and change it to the 
> > correct 
> > type in situ so that the error is not returned.
> > 
> > 2 is where my headache started. I've tried various things, checking to 
> > see if 
> > what's passed is an object or a sequence, but I am floundering a little, 
> > 
> > and 
> > any pointers would be greatly appreciated. Also, due to floundering, I'm 
> > 
> > a 
> > little sparse on detail - sorry.
> > 
> > At the moment, in order to experiment with with direct x, I'm having to 
> > use 
> > eu2.3, which is inconvenient more than anything.
> > 
> > Chris
> > 
>