OpenEuphoria

Re: Two nasty bugs in EC.EXE

• Posted by Robert Craig <rds at RAPIDEUPHORIA.COM> Jan 10, 2001
• 459 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