RE: [Gcl-devel] Re: delayed pathname.d patch

[Mike Thomas]

Hi Camm.

| OK, reverted in both branches (you already did the main.c in head).  I
| still think it would be nice at some point to change our winnt
| features labels to match some output in the configure canonical host
| string, but we'll defer this possibility for the future.

I agree wholeheartedly that it wold be nice, but it isn't going to work
because the host string on GNU tools on Windows, for better or for worse, is
coerced to reflect the name of the tools being used rather than the OS.  For
example with the MSYS/MinGW32 tools:

...
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
host=i686-pc-mingw32
The host is canonicalised to i386-pc-mingw32
...

If it had been a Cygwin system we would see "cygwin" instead of "mingw32".
This is not sufficient for our purposes for the following reasons.

1. On Windows, there is a set of libraries provided by Microsoft with the OS
which provides the Windows externally accessible OS functionality.  With any
Windows compiler you get headers and link libraries to use those system
libraries derived either directly from Microsoft or in the case of free
compilers such as MinGW32 and Cygwin from the publicly available
documentation put out by Microsoft.  The details of those libraries vary
according to the version of the OS and are, by convention, dealt with via
header macros, _WIN32 (Windows 32), _WINCE (Windows CE) and _WIN64
(according to reading I did, the forthcoming 64 bit Windows).

Those switches could certainly be examined in the configure script to
trigger appropriate lisp symbols eg win32, win64 and wince.  However, I
think it would be overly pedantic vis-a-vis the "autotools methodology"  to
define HAVE_WIN64 etc and then to potentially convert those macros in the
source code to the appropriate macros (_WIN64 etc).

Note that these issues are separate from the details of the various C
compiler runtimes which also need to be switched according to features such
as "mingw32", "cygwin" (which, as shown above, can certainly be switched on
the configure host string).   Those runtimes vary significantly including
functions which have the same name but which have varying semantics.


2.  There is the past baggage of the ill-chosen "winnt" feature which
apparently existed before we had anything to do with this project.

3.  It may seem bizarre that I am attempting to lay groundwork for support
for Windows CE, for example, but there is already a case where GCL (and
Maxima) has been ported to that platform, and so I think it wise to be
systematic about this stuff.  Windows 64 is, of course, looming.


| Also, please allow me to revert the debugging aids in head prog.c.
| They are a great idea in your personal tree to assist with gdb
| backtraces, but they are of course non-standard language features, and
| others use the head branch for real work (i.e. its not just a
| debugging branch).  Perhaps we could make a debugging branch if this
| would be of assistance?  Personally, I always have lots of
| uncommittable mods in my personal tree to help me figure out what is
| going on, and this appears to work OK.  If I drift too far from cvs,
| I'll rename the directory to test or some such and recheckout.

Sure - thanks for the suggestion.  Maybe at a more opportune time we could
set things up so that documented debug code is switched in and out with
the --enable-debug configure switch and placed in a debug package rather
than a separate debug CVS branch?


| > This stuff actually turned out to be a very interesting
| diversion as using
| > the Unix rather than winnt code (so presumably different
| warning switches)
| > in gcl_cmpmain.lsp I got a bunch of gcc warning messages including some
| > "possibly" uninitialised variables from the random tester:
| >
| > ....
| > 1200 gazonk3.c: In function `L1':
| > gazonk3.c:5235: warning: unused variable `V5'
| > gazonk3.c: In function `L5':
| > gazonk3.c:5231: warning: `V6' might be used uninitialized in
| this function
| > gazonk3.c: In function `L1':
| > gazonk3.c:5354: warning: unused variable `V4'
| > gazonk3.c: In function `L3':
| > gazonk3.c:5549: warning: unused variable `V11'
| > gazonk3.c: In function `L1':
| > gazonk3.c:5251: warning: `V2' might be used uninitialized in
| this function
| > gazonk3.c: In function `L1':
| > gazonk3.c:5482: warning: unused variable `V22'
| > 1300 gazonk3.c: In function `L1':
| > ...
| >
| > These messages never appeared before and I have yet to track
| them down - the
| > intermediate files are being deleted and the names are not
| being printed so
| > I'll have to modify the code to go further after I've done more
| on the path
| > corruption problem.
| >
|
| This is very interesting, and I'd personally be interested in knowing
| how your compiler flag setup wound up displaying these messages.  I'd
| taken some pains to make sure the generated C code had a clean -Wall
| compile, but I'd noticed that no warning messages, only errors, were
| displayed when I ran the compiler under lisp.  In other words, I had
| to run gcc on the command line on the output C files to see messages
| like the above, so conceivably there could be many cases of -Wall
| cleanups that I've missed.  What was the lisp input here?  I had
| pushed the gcc warning display issue way down on the future TODO
| list.

I'll try and follow up in detail this week; likewise your earlier suggestion
about the link time padding with respect to the stable branch instability
which I had overlooked.

Cheers

Mike Thomas.