RE: [Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()

[Mike Thomas]

Hi all.

On the weekend I wrote:

| PART 1: read_fasd()
|
| I happened on a combination of gcc optimisation flags which gave a
| repeatable hang on Windows in read_fasd1 (o/fasdump.c) while loading
| ansi-tests/rt.o.
|
| It turns out that the local variable "leng" in that function declared as
|   "int" receives an erroneous result from "getc()" via the GETD macro
| while reading the fasd data appended at the end of "rt.o":
|
|        case DP(d_short_string:)
|       fprintf ( stderr, "rf1 d_short_string, byte i = %x\n", i );
|       leng=GETD("leng=%d");
|       fprintf ( stderr, "rf1 leng = %d\n", leng );
|       leng = LENGTH(i,leng);
|       fprintf ( stderr, "rf1 Before READ_STRING, leng = %d\n", leng );
|       READ_STRING(leng,loc);
|       fprintf ( stderr, "rf1 After READ_STRING\n" );
|       return;
|
| The erroneous result is -122 which really should be 134 (134 + 122 =
| 256).  Redeclaring "leng" as "unsigned char" fixes that immediate
| problem but a crash occurs later anyway so presumably there are other
| places where such problems may be occurring.
|
| I suppose that this could be some interaction between the mixed
| optimisation settings and the "-fsigned-char" compiler flag and possibly
|   even the GCL custom linker.  Perhaps the C linker would normally do
| stuff to help optimise across module boundaries and seamlessly connect
| functions which have been optimised differently which our linker doesn't?

Having searched the MinGW32 mailing list, it turns out that this is a known
bug in MinGW32 runtime version 3.2 "getc()":

   http://sourceforge.net/mailarchive/message.php?msg_id=6311360


At this stage I don't know whether it applies to earlier versions of the
runtime but I would assume so.

Unfortunately 3.2 is the current version of the MinGW32 runtime.  I'll make
some enquiries.

Cheers

Mike Thomas.