I have a program that compiled under the Editor ok but aborted with an "Illegal record number" when accessing a particular file.

After much poking arround I found that if I complied the same program using Ashell/Linux (with the same options I had set in the Editor) COMPIL xxx /I/X:2 the program then worked fine!

Thought I would try updating compil.exe so downloaded the latest version from compil-5.1.467-w32.zip. The version number inside compil.exe is 5.1.465.0. Trying to use this to compile any program results in "Error executing the compiler! Check Compiler Settings under Project Settings...".

So then decided to try a previous version - 5.1.461 & 5.1.459 wouldn't compile the program "Illegal structure" error amongst others (the program doesn't have any structures). Finally got to 5.1.454 and it works!! Compiles the original program ok and the program runs correctly.

It looks like there may be something wrong with later versions of compil.exe - anyone using them successfully?

Barry

I'm using the 5.1.461 and, so far, didn't have any problem but, that doesn't mean there are no problem, maybe it's the case of you're using some feature in your program that pops up the issue.

Sorry to have overlooked this. Apparently there was a glitch in the 467 zip, but it's all mostly ancient history anyway, since the current version is 471, which you can download from the http://www.microsabio.net/dist/51dev/bin-win/ directory. Search for "COMPIL" in the release notes to see what has changed since 465.

Whether or not that actually fixes the problem I don't know, but if you get unexplained compil errors, please zip up the source and email it to me so I can resolve it.

Still getting problems.
I've isolated the section of code causing the compiler errors. Below is a sample.
This section appears at the beginning of most of our programs and didn't cause a problem before.

The error is "Expression stack overflow" on line 2 which is the "++IF RE'LEASE ..." line.

DEFINE RE'LEASE = 11
++IF RE'LEASE=11
DEFINE PRG'AREA = "R11RL:"
DEFINE PRG'NAME = "CHGASS"
++PRAGMA FORCE_FSPEC "R11RL:CHGASS.RUN"

DEFINE VERSION = "11.0"
PROGRAM CHGASS,11.0
++ELSE
DEFINE PRG'AREA = "R10RL:"
DEFINE PRG'NAME = "CHGASS"

DEFINE VERSION = "10.2"
PROGRAM CHGASS,10.2
++ENDIF

Barry

This appears to happen only in the compil.exe implementation (not in the embedded compiler invoked by compil.lit). Ironically, I think it is caused by some mixup in the conditional compilation logic of compil itself.

Stay tuned for version 472 ...

OK, I think the issue is fixed in compil.exe 5.1.472 (downloadable from compil-5.1.472-w32.zip )

The problem was introduced a few versions back while adding additional bounds-checking code to the expression handler to make sure that out-of-memory conditions were detected and reported before the stack got corrupted (in the middle of processing an expression involving large operands). One of the last tests added was inappropriate for the standalone compiler case (which uses the central A-Shell expression handler for evaluating ++IF directives, but otherwise has a totally different memory and stack configuration.)

The same issue probably affects the standalone Linux and AIX versions of the compiler, which I'll update shortly.

After updating I'm getting compile errors on this:
Don't know if it's relevant, but here is the map of the array in use with the problematic variables:
Here is the content of the LST file:

PRODQTD.BPI,152,Unmapped variable:conf'or'...,ar'cc'opcao(conf'or'comp, conf'or'comp'row) = opcao
PRODQTD.BPI,153,Unmapped variable:conf'or'...,ar'cc'factor(conf'or'comp, conf'or'comp'row) = FN'if'else'value(factor, 1)

I think this latest problem was introduced in edit 466 or 467 (a couple of months ago). The issue was the use of an ++extern'd variable as a subscript (which probably isn't very common).

I think it should be fixed in compil.exe 5.1.473 (downloadable from compil-5.1.473-w32.zip ).

The same fix will appear in the embedded compiler starting with 5.1.1196.6 (not yet posted, but should be within the next 24 hours or so).

I've been trying 472 and that seems to fix my orginal problem.

Thanks
Barry