Portable Dumper for native NT probably needs adjustment now that -subsystem:windows is used. I don't know how :-( Adrian config.inc: USE_PORTABLE_DUMPER=1 INSTALL_DIR=c:\XEmacs\XEmacs-$(XEMACS_VERSION_STRING) PACKAGE_PREFIX=c:\XEmacs HAVE_XPM=1 HAVE_PNG=1 HAVE_TIFF=1 HAVE_JPEG=1 HAVE_XFACE=1 DEBUG_XEMACS=1 GUNG_HO=1 MAKEINFO=d:\tmp\texinfo-4.0\makeinfo\makeinfo.exe COMPFACE_DIR=d:\tmp\libs4xemacs\compface JPEG_DIR=d:\tmp\libs4xemacs\jpeg-6b TIFF_DIR=d:\tmp\libs4xemacs\tiff-v3.4 ZLIB_DIR=d:\tmp\libs4xemacs\zlib PNG_DIR=d:\tmp\libs4xemacs\libpng-1.0.2 XPM_DIR=d:\tmp\libs4xemacs\xpm-3.4k # USE_CRTDLL=1 # USE_SYSTEM_MALLOC=1 > XEmacs Build Report as generated with > M-x build-report RET > by build-report-version $Revision: 1.3 $ follows: > Contents of d:\tmp\21.2\xemacs\Installation: > (Output from most recent run of ./configure) OS: Windows_NT XEmacs 21.2-b31 \"Iris\" configured for `i586-pc-win32'. Building XEmacs in \"d:\\tmp\\21.2\\xemacs\\nt\". Using compiler \"cl -nologo -W3 -Od -Zi -MDd\". Installing XEmacs in \"c:\\XEmacs\\XEmacs-21.2-b31\". Package path is \"~\\.xemacs;;c:\\XEmacs\\site-packages;c:\\XEmacs\\xemacs-packages\". Compiling in support for Microsoft Windows native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for TIFF images. Compiling in support for JPEG images. Compiling in support for X-Face message headers. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for widgets. Compiling in support for native sounds. Compiling in fast dired implementation. Using minimal tagbits. Using indexed lrecord implementation. Using portable dumper. Using system malloc. Using DLL version of C runtime library Compiling in extra debug checks. XEmacs will be slow! > Contents of d:\tmp\21.2\xemacs\nt\xemacs-make-all.err > keeping lines matching > "^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\( \s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+" > and then deleting lines matching > "confl.*with.*auto-inlining\|^Formatting:" cd d:\tmp\21.2\xemacs\nt\ nmake /f xemacs.mak all Compilation started at Tue Mar 14 00:28:05 2000 +0100 (W. Europe Standard Time) Installing XEmacs in \"c:\\XEmacs\\XEmacs-21.2-b31\". 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. ..\src\alloc.c(5096) : warning C4090: 'function' : different 'const' qualifiers ..\src\alloc.c(5096) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1 ..\src\nt.c(1411) : warning C4273: 'fstat' : inconsistent dll linkage. dllexport assumed. ..\src\nt.c(1446) : warning C4273: 'stat' : inconsistent dll linkage. dllexport assumed. ..\src\nt.c(1735) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(int )' ..\src\process-nt.c(447) : warning C4028: formal parameter 2 different from declaration ..\src\process-nt.c(447) : warning C4024: 'EnumWindows' : different types for formal and actual parameter 1 msvcrtd.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain＠16 ..\src\temacs.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Compilation exited abnormally with code 2 at Tue Mar 14 00:32:26

On Mon, Mar 13, 2000 at 10:22:24PM -0700, Ben Wing wrote: > OK, here's a fix. I also fixed alloc.c; nt.c is harder ... later. > Index: src/alloc.c > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/alloc.c,v > retrieving revision 1.42.2.57 > diff -u -r1.42.2.57 alloc.c > --- alloc.c 2000/03/13 07:27:50 1.42.2.57 > +++ alloc.c 2000/03/14 04:58:19 > ＠＠ -5093,7 +5093,12 ＠＠ > } > > /* Put back the lrecord_implementations_table */ > - memcpy (lrecord_implementations_table, p, sizeof (lrecord_implementations_table)); > + /* We cast to void * because otherwise VC++ gives a warning. > + This seems like a bug in VC++ in its handling of const, > + but who knows? const is very tricky and fundamentally unworkable; > + there is no const in Java because all attempts to create one that > + was actually enforced were failures. */ > + memcpy ((void *) lrecord_implementations_table, p, sizeof (lrecord_implementations_table)); > p += sizeof (lrecord_implementations_table); > > /* Reinitialize lrecord_markers from lrecord_implementations_table */ Veto. I don't want us to add casts to silence _buggy_ compiler _warnings_ that may hide real problems in the future. For instance, the day the lrecord_implementations_table becomes a const table. OG.

On Wed, Mar 15, 2000 at 03:19:55AM -0700, Ben Wing wrote: > Oh puhleeeze Olivier, don't give me that anti-MS shit. That wasn't anti-MS. That was anti-cast. I had to track down too many breakages due to unnecessary casts (especially on 64bits architectures) to accept adding junk ones to silence buggy warnings. Even gcc warnings, mind you. I'd rather spend time fixing gcc. The only ones I accept (with clenched teeth however) are the casts-from-void* necessary to make the C++ compilers happy, and that's because they otherwise spew out errors. > That cast in memcpy cannot possibly introduce a bug. What do you think I meant by that: > > For instance, the day the lrecord_implementations_table becomes a > > const table. We may decide someday to change the table into a constant one (after all it is a table of pointers to constant structures with constant indexes). If someone forgets about the memcpy, it may or may not segfault, depending of the phase of the moon. OG.