1. Two nasty bugs in EC.EXE
- Posted by Jack Cat <catjackus at yahoo.com> Jan 09, 2001
- 520 views
I encountered a very nasty bug, and an incompatability issue in EC.EXE. 1. I tried to translate a program wich uses NEIL.E into C for DJGPP. EC.EXE tells me that built-in pixel() is being redfinied, while inte interpreter runs the program without errors. I did not include graphics.e nor image.e, just neil.e. 2. I translate Jiri's flowers.ex program wich comes with his map.e library. Once compiled and linked, I try to run it, yet get a very nasty dos extender crash immediatly after the delay. Yet the interpreter runs flowers.ex without any problems. Robert, please fix these bugs, especially that last one, for it's very, very nasty. Mike The Spike __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/
2. Re: Two nasty bugs in EC.EXE
- Posted by Robert Craig <rds at RAPIDEUPHORIA.COM> Jan 10, 2001
- 460 views
Mike The Spike writes: > 1. I tried to translate a program wich uses NEIL.E > into C for DJGPP. EC.EXE tells me that built-in > pixel() is being redfinied, while inte interpreter > runs the program without errors. I did not include > graphics.e nor image.e, just neil.e. It's true that pixel() is redefined in neil.e, and in the absence of "without warning" you will see a warning message about it. Don't confuse warning messages with error messages. ec will produce warnings, just like the interpreter. It doesn't mean you can't run your .exe. > 2. I translate Jiri's flowers.ex program wich comes > with his map.e library. Once compiled and linked, I > try to run it, yet get a very nasty dos extender crash > immediatly after the delay. Yet the interpreter runs > flowers.ex without any problems. > That second bug in EC.EXE I just posted turned out to > be a missing bitmap file in the directory wich > flowers.ex needed to run. > This is still a bug, since I expected a runtime error > message, not a crash. No, it's not a bug. The crash occurs because Jiri's code does not allow for the possibility that read_bitmap() will return an integer error code when it can't find the bmp file. So you have something like this: x=read_bitmap("3f.bmp") pal=x[1]/4 Here, Jiri is assuming that read_bitmap() will never fail. He is assuming that a sequence will always be returned. When 3f.bmp does not exist, x is set to error code 1, x[1] therefore makes no sense. The interpreter checks for stuff like this and issues an error report. The translated C code does not check, and a crash occurs. The translator assumes that you have debugged your program. In the interest of maximizing speed it eliminates most checks. There are still a few checks in the runtime routines that are shared between the translator and the interpreter, so you will occasionally get a ex.err file, but for the most part if you make a stupid error "all bets are off" and an ugly crash is likely to occur. (Just like with hand-written C programs.) When your .exe crashes, you should run the program again using the interpreter to find your mistake. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com