lah@raybed2.ray.com (LANCE HOLMES) (03/07/90)
I just got my update to Aztec manx C and thought I would try it out. I always find it interesting to recompile a program when I get the source to see if first I can in fact recompile it and also to see if I get a different size file for the executable. So I tried to recompile MicroEmacs 3.10. Well first of all, as any of you who have received their update know, Aztec has changed the options used with the compiler. So I modified the makefile and went on. The second problem the compiler had with the code was the use of some constants that were being returned. So not to spend a lot of time on this problem I changed them to variables and assumed that the program would treat them as constants anyway. The next problem the compiler had was with a statement in the module input.c . It said that the statement was to complex and that I should simplify it and recompile. Well I'm not and expert but I have a good understanding of C and couldn't see where the statement was all that complicated. I gave up after that error and feel that I going to hold on to version 3.6 of the Manx C compiler and docs for a while seeing how there does seem to be a variety of differences. Lance Holmes
plav@cup.portal.com (Rick M Plavnicky) (03/12/90)
At 05:48 on 3/7/90 lah@raybed2.ray.com (LANCE HOLMES) writes: > I just got my update to Aztec manx C and thought I would try it out. > I always find it interesting to recompile a program when I get the source > to see if first I can in fact recompile it and also to see if I get a > different size file for the executable. So I tried to recompile > MicroEmacs 3.10. That's one of the first things I did, too. Like you, I changed the makefile, made a couple of other minor changes, and... > The next problem the compiler had was with a statement in the module > input.c . It said that the statement was to complex and that I should > simplify it and recompile. Well I'm not and expert but I have a good > understanding of C and couldn't see where the statement was all that > complicated. Yeah. The first place this happens is around line 360, in the function comp_command(). The 'complex' code looks like: ... if (matchflag) { /* if this is the first match, simply record it */ if (match == NULL) { match = bp; name[*cpos] = bp->n_name[*cpos]; } else { /* if there's a difference, stop here */ if (name[*cpos] != bp->n_name[*cpos]) return; } } ... > I gave up after that error [...] Ah, casting *cpos to char seems to do the trick, but I can't see why the compiler complained in the first place. Try: ... if (matchflag) { /* if this is the first match, simply record it */ if (match == NULL) { match = bp; name[(char)*cpos] = bp->n_name[(char)*cpos]; } else { /* if there's a difference, stop here */ if (name[(char)*cpos] != bp->n_name[(char)*cpos]) return; } } ... > [...] and feel that I going to hold on to version > 3.6 of the Manx C compiler and docs for a while seeing how there does > seem to be a variety of differences. Well, there've been quite a number of Manx 5.0A bug reports on the net lately (er, but not as many as Lattice has attracted, it seems to me :) ). But I, too, am keeping the 3.6a package around. Wanna *really* see some fireworks? Try compiling VT100 2.9A with 5.0. Whew! Anyway, I *did* get emacs 3.10 going, and after optimization it even shrunk a few K. Seems at least as solid as it was under 3.6a... $ list c:emacs emacs 105376 ----rwed 30-Jan-90 18:45:44 > Lance Holmes Rick Plavnicky {...}!sun!cup.portal.com!plav "I've got a bunch of bananas, and a bottle of bleach!"