On (13 Sep 96) Paul Edwards wrote to Roy McNeill...



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



 PE> But this does not solve the problem with the executable that comes in

 PE> indentpe.zip, on your system.  That is still unresolved, yeah?



 RM> Correct. I gave up.



 PE> Ok.  If you want that to work, you'll basically need to get the compiler

 PE> and figure out what indent is doing wrong.  I can't reproduce the problem

 PE> here.



Never mind. But I'll pick up the compiler anyway, just for fun.



 RM> Ok, but it may take a week or two to tidy it up. I'll try to get

 RM> the warning list below 50 while I'm at it.



 PE> It's probably not a good idea to do that.  Minimal changes are the order of

 PE> the day I reckon.  Because otherwise you're going to get a completely

 PE> diverging version of indent, with no chance that it gets into the original

 PE> author's work (and thus becomes someone else's job to maintain!).



Forget it, then, that source code needs too many band-aids. Just to

get it to compile without errors I had to add twenty-one



 #include 



statements; to eliminate "function called without prototype"

warnings I had to write six new header files and add another twenty

odd #include lines.



A big bunch of functions are written in the ten year old



 int function (a,b)

  int a,b;

 {...}



style - I'm not sure if the compiler can spot type mismatches in

this style, I'll try it out later.



The function diag() in io.c is called in two different ways, using

an obfuscated technique which the compiler rejects if the function

is properly declared in a header file. Sure, it works, but if

cunning tricks like that are undocumented, they can take a running

jump as far as I'm concerned. Especially when the fix is relatively

trivial.



The functions xmalloc and xrealloc in globs.c need to call

farmalloc and farrealloc instead of malloc and realloc if they are

going to return far pointers (i think the borland setup is broken

here, the return type should depend on the memory model IMO).





 RM> I might try an arrangement like



 RM> #ifdef __BORLANDC__

 RM> #define HugeChar   char huge

 RM> #else

 RM> #define HugeChar char

 RM> #endif



 RM> and use HugeChar for the pointers in io.c that I want to be huge.



 PE> Why do you need huge pointers, and can't you just compile it huge anyway?



Good point. I haven't had to muck around with memory models much;

that idea hadn't occurred to my conscious mind (although a small

gremlin had been screaming "Huge! Huge! Huge!" at me for days, but

I thought he was talking about something else altogether.)



Also, I was using Borland's 16 bit dpmi extension, and the memory model

for that appears to be fixed at "large", the documentation isn't

very explicit here. But if I restrict the source file size to <64k,

the ordinary non-dpmi huge model should work ok.



Btw, huge pointers are needed because pointer subtraction is used

to get lengths of strings in the source buffer.



Again, ta for help.



Cheers



--- PPoint 1.88