Hi Paul



 RM> Now what?



 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 already?



I had a harder look at the source code, thinking Dos thoughts.

Since it uses pointer arithmetic quite a bit in IO.C, I declared

every char pointer in sight as huge. Since it reads the entire

source file at once, I then compiled it using Borland's dpmi

extensions, then used the debugger to find the main problem - the

line



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



Borland's fprintf wants an int as the third parameter, not the long

int that the pointer subtraction supplied. Changing the line (and a

related line or two) to



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



produced an exe that worked, although I haven't given it a decent

test yet. It still compiles with over 100 warnings... The dpmi

version is certainly more rugged, it aborts with a GPF (!) if a

wild pointer gets too wild. Nice.



One thing I'll probably add is the ability to put comments in the

INDENT.INI file. The commands are rather cryptic, and vary a bit

between versions, and I wouldn't use them often enough to learn

them. The approach I think I'd use would be to place each command

on its own line, with any text that doesn't start in column 1

ignored.



Ta for all the assistance (and abuse)



Cheers



--- PPoint 1.88