Sorry for the long delay before replying.
The problem and the solution you suggest are clear, but I'd like to
try to find a cleaner solution, if possible, one that doesn't require
so many #ifdef's. Can you think of some change in one or two places
that would resolve this? Can MSVC be forced in some way to use an
unsigned type for enumerations, for example? If not, since the
problem is only with a single enumeration, would it work to use
something like this:
enum Lisp_Misc_Type
{
Lisp_Misc_Free = 0x5eab,
Lisp_Misc_Marker = 0x5eac,
Lisp_Misc_Intfwd = 0x5ead,
etc.? Or maybe use 0x5eabU etc., with an explicitly unsigned value?
No, that doesn't work. And somehow, I'm glad that the compiler can't be fooled this way.
After looking around and googling about this issue, the problem is trickier than what I thought
at first. Even my first explanation may not be complete. Anyway, mixing enum and bit fields
seems to be incompatible with portability. Either you need to step back and type bit fields
with int or unsigned int (and loose typechecking) or you need to get around with macros
taking care of using enum or unsigned ints depending on the compiler.
A few other issues with the rest of the patch:
> -# define DECL_ALIGN(type, var) \
> +# define DECL_ALIGN(type, var) \
> type __attribute__ ((__aligned__ (1 << GCTYPEBITS))) var
Is this just some inadvertent reformatting, or is there some deeper
problem here?
Only reformatting, sorry. I'm not even sure that I needed to define DECL_ALIGN for msvc,
because I set an option on the command line to align everything.
> TAGS-gmake:
> - ../lib-src/$(BLD)/etags.exe --include=TAGS-LISP --include=../nt/TAGS \
> - address@hidden/nt/emacs-src.tags \
> - $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0))
> - ../lib-src/$(BLD)/etags.exe -a address@hidden/nt/emacs-src.tags \
> - $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1))
> - ../lib-src/$(BLD)/etags.exe -a address@hidden/nt/emacs-src.tags \
> - $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \
> - $(CURDIR)/*.h
> +# ../lib-src/$(BLD)/etags.exe --include=TAGS-LISP --include=../nt/TAGS \
> +# address@hidden/nt/emacs-src.tags \
> +# $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0))
> +# ../lib-src/$(BLD)/etags.exe -a address@hidden/nt/emacs-src.tags \
> +# $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1))
> +# ../lib-src/$(BLD)/etags.exe -a address@hidden/nt/emacs-src.tags \
> +# $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \
> +# $(CURDIR)/*.h
Why did you comment out these commands? They are not supposed to be
invoked under nmake, only under GNU Make.
They are not invoked, but the problem is that they are not parsable. Nmake fails to read the makefile.
> - memset (bloc->new_data + old_size, 0, size - old_size);
> + memset ((char *) bloc->new_data + old_size, 0, size - old_size);
Is this a real problem, or just a left-over from some attempt to debug
memory allocation problems, resolved by "-dynamicbase:no"? If this is
a real problem, can you tell what it is?
MSVC can't/doesnt want to do arithmetic on void pointers.
> +#define fstat(a, b) sys_fstat(a, b)
> +#define stat(a, b) sys_stat(a, b)
> +#define utime sys_utime
Why did you need to do this? What happens if you don't?
If I don't do it, I get linking errors :
temacs2.lib(sysdep.obj) : error LNK2019: unresolved external symbol __imp__stat referenced in function _sys_sigblock
temacs2.lib(image.obj) : error LNK2001: unresolved external symbol __imp__stat
temacs1.lib(dired.obj) : error LNK2001: unresolved external symbol __imp__stat
temacs1.lib(lread.obj) : error LNK2001: unresolved external symbol __imp__stat
temacs1.lib(w32.obj) : error LNK2001: unresolved external symbol __imp__stat
temacs1.lib(fileio.obj) : error LNK2001: unresolved external symbol __imp__stat
temacs2.lib(sysdep.obj) : error LNK2019: unresolved external symbol _utime referenced in function _set_file_times
There are these 2 lines in src/s/ms-w32.h :
#if !defined (_MSC_VER) || (_MSC_VER < 1400)
#define tzname _tzname
#define utime _utime
#endif
If I raise the 1400 to a higher value to include my version of the compiler, the compiler reports an error message about :
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\time.h(270) : error C2090: function returns array
because tzname is defined as an array and that triggers a conflict.
Why would it be a problem to map thos three calls to their sys_ version ? Performance ?
> - if (tmp && _access (tmp, D_OK) == 0)
> + if (tmp && sys_access (tmp, D_OK) == 0)
What's wrong with calling _access from the MS runtime?
_access doesn't know about D_OK. Worse, D_OK is defined, it hides the fact that _access
doesn't know about it. But _access crashes with this value. Anyway, sys_access is defined, so why
not using it ?
> - " --cflags", USER_CFLAGS,
> + " --cflags", stringer(USER_CFLAGS),
Why did you need to stringify here? USER_CFLAGS is supposed to be
defined to a quoted string, like " -DFOO". Can you tell why this
didn't work for you?
Oops. I used this hack long ago, and I reintroduced it. But my real problem is that user_cflags contains
various -I<path> to find include files, and these paths have \ that are not doubled.
Stringifying is a bad idea and doesn't solve the problem at all. Need to find a better solution.
> +rem set SDK environment
> +if (%noopt%) == (Y) (
> + call "c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /win7 /Debug
> + set nodebug=N
> +)
> +
> +if (%nodebug%) == (Y) (
> + call "c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /win7 /Release
> + set noopt=N
> +)
Is there a less system-dependent way of doing this? E.g., is there an
environment variable to replace the path to SetEnv.cmd?
You may have several versions of the SDK. I put these lines to stress the fact that people wanting
to compile emacs with the MS SDK need to set it up. Also, iti is needed to set it up according to the debug/release mode.
Also, how to
set the /win7 switch portably, so that it works on non-Windows 7
platforms as well?
This /win7 switch is unnecessary.
For that matter, is it at all necessary to call
SetEnv.cmd, in addition to using appropriate compiler/linker switches?
I guess so, yes, to find the compiler, the include files and the libraries.
Also, note that to copile the whole thing, I need to run :
nmake USE_CRT_DLL=1
My best wishes for 2011.
Happy New Year.
Fabrice