PE> And if it still doesn't work, well, it needs to be debugged.  How about
PE> FREQing GNUEMX.TXT, then the files it refers to, then you will have a free
PE> 32-bit DOS-extended C compiler.  Which you can run zatest on, and it takes
PE> parameters successfully, then you can find out which change from zatest to
PE> indent stuffs it up. I presume you have made sure that all the stuffing
PE> around you did with indent yourself, you haven't altered something 
PE> already?

RM> I had a harder look at the source code, thinking Dos thoughts.
RM> Since it uses pointer arithmetic quite a bit in IO.C, I declared
RM> every char pointer in sight as huge. Since it reads the entire
RM> source file at once, I then compiled it using Borland's dpmi
RM> extensions, then used the debugger to find the main problem - the
RM> line

RM> fprintf (output, "%.*s", e_lab - s_lab, s_lab);

But this does not solve the problem with the executable that comes in
indentpe.zip, on your system.  That is still unresolved, yeah?

RM> Borland's fprintf wants an int as the third parameter, not the long
RM> int that the pointer subtraction supplied. Changing the line (and a
RM> related line or two) to

RM> fprintf (output, "%.*s", (int)(e_lab - s_lab), s_lab);

Yes, that is correct, the first version was buggy.

Ok, so can you tell me again what is the total (and minimal) of the changes
you had to make to make the source code work with Borland? So long as they
aren't dirty global changes, I'd like to modify my version so that it works
with Borland.

RM> Ta for all the assistance (and abuse)

We aim to abuse!  BFN.  Paul.
@EOT:

---