Maurice Lombardi wrote:
I had the same results with v2.03p2 (never tried v2.04) y2k.pas has random failures since long time, apparently due to trigger of a Window function to change between summer/winter time when the program changes date to some seconds before y2k to make the test: it appears more clearly, but still randomly, by increasing the time delay included in the test. I simply ignore it.
Well, the test was written to test some "__BP_UNPORTABLE_ROUTINES__" as it clearly indicates. As far as I'm concerned, I don't have to keep this test if it now doesn't even work (reliably) on its "native" platform.
Alternatively, we could activate the work-around (simulate a changed time for the running program and leaving the system time alone) for DJGPP as well. If you prefer this, it's the conditional in dos.pas:741 (`{$ifdef __GO32__}'). Let me know if I should change it permanently.
At this time DJGPP distribution has bad gcc-3.3.5 binaries (C++ broken, what I unfortunatelly didn't notice before uploading). So I'll going to reupload updated archives. Is it reasonable to put also GPC-20041218 in, when I upload archives for DJGPP distribution?
There is still the problem of CPP_PREDEFINES which are broken in gpc for gcc > 3.2.3. This is an anoyance for all DOS / windows backends which use them heavily, e.g. in crt, graph units. This is not seen in the test suite because a work around is used in it, but it appears in ordinary programs. I have not uploaded 3.3.x binaries in the gpc site for that reason. Apparently none of the user is able to contribute a solution, and main gpc maintainers (Franck and Walter) are too busy with important improvements of gpc (range checking and qualified imports are very important improvements for all of us).
Yes, I was busy with them. But integrating the preprocessor (which will fix those issues) is still high on my list, I didn't forget about it.
Frank