Re: cdecl support

new topic     » goto parent     » topic index » view thread      » older message » newer message

-------Phoenix-Boundary-07081998-

Hi Robert Craig, you wrote on 2/27/02 2:53:54 PM:

>
>Unfortunately, there is no consistency.
>You don't have to have "@n" in the name for it
>to be _stdcall. Just look at all the Windows API routines.
>
>My notes were taken from one particular C compiler,
>and all C compilers have a way for the programmer to
>change the function name to anything he likes.
>
What a pity.

Functions which take parameters reveal their convention
by changing ESP, or not.
Return values that are something other than doubles, floats,
or structures are the same in either convention.
Functions which return structures are not supported by
Euphoria.

Currently Euphoria only fails on _cdecl's that return
float or double. Compilation with a compiler other than
Watcom causes failure on all _cdecl's that take
parameters.

Euphoria could easily be modified to only fail on
_stdcall's that returned a float or double,
   and took no parameters
   and were named with a leading underscore.

Alternately:
It could easily be modified to only fail on
_cdecl's that returned a float or double,
   and took no parameters
   and were named without a leading underscore.

Is that about right?

The changes would extend Euphoria's coverage from
maybe 97% of dll's to maybe 99%, which is either
a small or a large gain, depending on how you
look at it.

If any source code hacker is interested, I can supply
the fixes that restore Euphoria-like behavior to
the output of LCC.

Karl Bochert

-------Phoenix-Boundary-07081998---

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu