[Ecls-list] Latest fixes

[Goffioul Michael]

> 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.

I fully agree. However, you then must make sure that "math.h" is
not included after "object.h". As an always-working-but-ugly hack
I undefined "complex" only when required.

> 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.

I understand. As I said, I only get compiler warnings, not errors.
You can leave it as it is now.

> 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.

I know, this is still something to be fixed. In the beginning, I used
the same scheme as mingw32, defining "sys" as the directory part of
argv[0]. However this didn't seem to work as when calling ecl in the
current dir simply with "ecl", it couldn't find "sys:cmp" although 
cmp.fas was located in the very same dir. Moreover I wondered it this
would still work if I add ECL bin dir to PATH and call ecl without any
directory.

Michael.