[Ecls-list] Latest fixes

[Juan Jose Garcia Ripoll]

Goffioul Michael wrote:

>>* Port of ECL to Microsoft VC++ by Goffioul Michael. I have mostly 
>>incorporated his patches, together with a new directory (ecl/msvc) in 
>>which ECL can be build using NMAKE and MSVC++. This ports includes 
>>rudimentary support for winsocket lisp streams.
>>
>I have some issues though, because it doesn't work as-is. Attached
>you'll find a small patch to make it work:
>1) you need to undefine "complex" because MSVC defines "complex" to
>"_complex", which makes compilation fails; I worked around it in print.d
>
I thought I had undefined this in object.h But you are right that this 
might not be enough. What I did not want is to have #undefine complex 
everywhere. A single occurrence should be enough.

>2) "__attribute__" function modifier is still use in one function
>definition in external.h
>
I have fixed this by defining __attribute__(x) as an empty macro.

>Regarding non-returning functions, you have now removed all the
>__attribute__((noreturn)) modifiers. I don't know if this is the
>right thing to do, but you now get a lot of compiler warnings
>because of functions that should return a value. Wouldn't it be
>better to still use the "noreturn" attribute but make it compiler-
>dependent, through a macro for example:
>
The problem I found is that compilers assume more than "noreturn" from 
such functions. For instance, GCC assumes that the function will not 
call longjmp(). In other words, it assumes that one will not return to 
any point in the function that calls a noreturn piece of code. This 
leads to wrong code for
    if (setjmp(buf) == 0) {
        /* Beginning of an UNWIND-PROTECT */
        ...
        /* Here the debugger might be activated and the user might
           choose to "throw" and jump to an outer handling point */
        FEerror("Some lisp error",0);
        ...
    } else {
        /* Code for the UNWIND-PROTECT when an error occurred */
    }
These bugs are really difficult to track and I would rather avoid them, 
until somebody assures me 100% that GCC and all other supported 
compilers will interpret the noreturn attribute correctly.

Juanjo

P.S.: I think for the installation you should consider a more flexible 
scheme that does not hardcode the directory in the Makefile, but rather 
uses some temporary directory + the NSI program and script in src/util/ 
for producing self-installing executables. You simply have to mimic what 
the mingw32 port does. Furthermore, you should understand that ECL is a 
relocatable executable, that for the WIN32 port does not have the 
installation directory hard-coded in the program: it just assumes that, 
wherever ecl.exe is, the libraries and headers and other files will also 
be there.