X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Message-Id: <3.0.1.16.20040215122529.34ef6022@earthlink.net> X-Sender: ethros AT earthlink DOT net X-Mailer: Windows Eudora Light Version 3.0.1 (16) Date: Sun, 15 Feb 2004 12:25:29 -0500 To: djgpp AT delorie DOT com, Eli Zaretskii , Charles Sandmann From: Ethan Rosenberg Subject: Re: Cross Platform Incompatabilites? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear Listmembers - I thought that the problem could be from not including float.h [is this needed anytime a float is used??] Just including float.h and omitting the calls to _control87 and crt0_startup_flags did not change anything. I then followed the advice of both Eli Zaretski and Charles Sandman and included both the above calls. The problem still persists. [see below]. MUCH THANKS IN ADVANCE FOR ANY AVICE WHICH WILL BE GIVEN. Ethan Rosenberg ********************* >Return-Path: >Date: 12 Feb 2004 08:00:35 +0200 >From: Eli Zaretskii >To: Ethan Rosenberg >Subject: Re: Cross Platform Incompatabilites? >Reply-to: Eli Zaretskii > >> Date: Thu, 12 Feb 2004 00:04:11 -0500 >> From: Ethan Rosenberg >> >> Eli - >> >> Sorry for the delay in my reply. I am NOT an expert in C programming. My >> training is in chemistry, and the programming is all self-taught. I hope >> my questions to you are not infantile. > >Your questions aren't infantile, but please consider continuing this >discussion on the news group, where other knowledgeable people could >help with ideas and advice. > >> My DOS machine: >> >> DOS 6.1 running on a 66 MHz 486, with a Intel Pentium Overdrive to 83 MHz, >> and 64 Meg RAM. [Dell Optiplex 466/L] >> >> Wife's computer: >> >> Windows 2000 Professional Edition on a 2.4 GHz (?) Intel Pentium 4 [Dell >> Optiplex GX260] 256 Meg (?) RAM >> >> Work Computer: >> >> Windows 98 on a 650 MHz AMD Athlon. 256 Meg (?) RAM > >These are very different configurations. Which one of them gives bad >results (sorry, I forgot and don't have your original message handy >where I type this)? > >> > Any chance one of them uses an FP emulator? >> I don't know. How do I find out?? > >With the hardware you have, I think none of them uses the emulator. >The emulator is only used if the CPU lacks FP hardware, which isn't >the case here. > >> >Bad addresses might be one possible cause, yes. You may wish to try >> >to run the program on the pure DOS configuration under YAMD (which can >> >be downloaded from the DJGPP FTP site), and see if it catches any such >> >bugs. >> >> I could not find it on the DJGPP site. I did a search and came up with a >> number of hits for YAMD. Which site should I use? > >It looks like there's no valid URL for YAMD. I could mail it to you, >I still have the package on one of my machines. But it might be best >to try other approaches first, see below. > >> One of the FAQs that I >> saw referred to needing upwards of 131 MB of memory, which I do not have. > >There's no need for 131MB of physical memory, don't worry about that. > >> >Another possibility could be some FP exception that is generated by >> >the program on one of the platforms. The DJGPP library docs describe >> >a function _control87 that can be used to set the x87 FPU so that it >> >triggers SIGFPE whenever a bad float result is produced. One idea to >> >debug this is to enable FP exceptions like that and see if any SIGFPEs >> >happen on one of the platforms. If you do get SIGFPEs, it almost >> >surely means some kind of data-dependent bug. >> >> I read the documentation for _control87, but it is not obvious to me how to >> implement it. Would you please give me an example of code to use. Thanks > >The call > _control87(0xf, 0xf); > >near the beginning of your `main' function should accomplish what I >suggested. This call causes the FPU to raise an FP exception for >invalid operation, denormal operand, divide by zero, and overflow in >FP operations. > >One other thing to try is what Charles Sandmann suggested: set >the_CRT0_FLAG_FILL_DEADBEEF bit in the _crt0_startup_flags variable >(see the documentation of _crt0_startup_flags in the library reference >for the details). If your program uses uninitialized memory, this >will change the results and/or cause some exceptional conditions that >you should be able to observe. In any case, if this flag changes the >results on any of the platforms, it's a clear sign of using >uninitialized memory (i.e. bad pointers). > >