MARSELLE%gmr.com@RELAY.CS.NET (07/28/87)
This note is for John Weald at Auscom, Inc. in San Jose who asked about porting lex and yacc-generated C code to an IBM PC-AT. Since I can't seem to be able to reach him with a uucp net address (we're on csnet here at GMR, the place with the funny userids based on Social Security numbers, remember?), I'm posting it back to info-unix. Please bear with me. John, I've ported the C source produced by Lex and Yacc to an IBM PC-AT running DOS and compiled it with a Microsoft C compiler and linked it with the Microsoft linker and have had surprisingly little trouble. I used a Sun workstation to do the development work. Some notes: Makefiles on Unix are arranged a bit differently than those on the PC (Microsoft provides a "make" with their C compiler). On Unix you can have multiple objects in a makefile, if you say "make", make makes the first object named in the makefile. If you say "make object", make looks for that object in the makefile and then deals with it. As best I can tell, Microsoft "make" only deals with one .exe file (load module), and it has to be dealt with at the bottom of the makefile (the link edit step). First comes all of the compiles of all of the source modules. I'd suggest using lint just to check for portability of the code you write; you don't have control over the code lex and yacc write. Lex sticks a #include "stdio.h" in at line 1 of lex.yy.c; since I do a #include "lex.yy.c" in my yacc file, this caused a compile error on DOS since I had already included stdio.h in the yacc file. Also, I don't think DOS like filenames with three parts, so I rename y.tab.c and lex.yy.c before I copy them over to the PC (I use PC-NFS, which lets you mount a Sun directory from the PC and ships file over thin-Ethernet via a DOS COPY command). I found one bug in my code which concerned my forgetting to declare atol() as a function returning a long integer. Since ints=longs on the Sun (32 bits), I never had a problem. When I moved the code to the PC, I had a problem (int = 16 bits, long = 32) with negative numbers. Lint might have helped there if I had used it. Another interesting thing concerned another bug. I was calling malloc() to allocate data structures and I forgot to initialize certain fileds in the structures. Since malloc() on the Sun clears the memory which gets allocated and since the fields in question were supposed to have been initialized to zeros, I never noticed a problem. When I moved the code to the PC, I found that malloc() doesn't clear the memory and so my fields had garbage in them. So this was a case where porting the code helped me find a bug. The guy I'm working with on this project is developing on the PC and I've ported his code to the Sun. There's been some cases where porting in this direction has uncovered bugs in his code, too. For one thing, if you dereference a bad pointer in DOS, you never know it. If you dereference a null pointer, you'll get an error message "Null pointer reference" after the program exits, not at the time that it occurs, which isn't very helpful for debugging. Of course, executing such code on the Sun will generate a Memory Fault and produce an immediate core dump. ____________________________________________________ |Jim Marselle | Phone: (313) 986-1413 | |GM Research Labs | csnet: marselle@gmr.com | |Computer Science Dept. | ^^^^^^^^ | |30500 Mound Road | At least we don't use funny |Warren, MI 48090-9057 | userids on our VAX (yet) | ----------------------------------------------------